QOF-to-SQL Proof of Concept

[Benjamin Carlyle]

On Thu, 2004-05-27 at 00:14, Derek Atkins wrote:
> linas at linas.org (Linas Vepstas) writes:
> > but SQLLite is single-user, right?  No multi-user support.
> No, there is multi-user support in SQLite (at least according to their
> website).  It lock()'s the database file for writes.

I think I've been involved with this discussion on the list before :)
When you talk about sqlite being multi-user, it depends on what you mean
by multi-user. If you mean that multiple writers can be active in the
same database at the same time, no it's not. If you mean that an
unlimited number of readers can be simultaneously active, then yes. It's
multi-user. If you mean that multiple threads across multiple processes
can access the database without having to manage their own locking
semantics to avoid database corruption, it's multi-user. Sqlite is
designed to allow multiple threads across multiple databases to access
the database simultaneously. If a reader is active, an unlimited number
of other readers may also be active. If a writer is active, no other
writers and no readers may be active. All locks apply to the database as
a whole, and no page- or row-level locking is available.

It is proposed that the next version of sqlite (3.0, due sometime in the
next couple of months) will allow a writer to operate concurrently with
an unlimited number of readers, but would still lock out other writers
on the database. No support for finer-grain locking is currently
planned. If you want that kind of multi-user support you need to start
using a client-server database system such as postgres or mysql. In the
mean-time sqlite will blow them both out of the water in terms of
performance for any kind of database that only a single or small number
of processes need to access concurrently.

Benjamin.