On Thu, 2004-05-27 at 00:14, Derek Atkins wrote: > [EMAIL PROTECTED] (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. _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
