In most (if not all) of the situations I've seen people mention where concurrency is a problem (and in our own similar situation), it looks as if the problem is all in 'single application, multiple threads'
In this case, some of the problems which SQLite are struggling to solve will never happen, eg, file locks are actually unnecessary, and the section 1.3 becomes less of an issue (SQLite could actually work like a client-server database and treat the journal as a recovery mechanism only)
I wonder if there couldn't be a case for 'formalising' this behaviour. So, you could specify that an *application* wants exclusive access to a particular SQLite database. So, once the DB is opened, a file lock is put on it, until the application closes.
So, the application could call a different API at startup to grab ownership of a DB file, and set up the finer grained lock tables that might be necessary, and then each thread could call something like sqlite_open, with a reference to a handle created by this first API call.
So, in effect, SQLite would gain a lot of the advantages of 'client-server' (ie single application, therefore more flexible locking facilities, easier fair queuing etc ) without the extra complexities involved (eg inter-process/network communications facilities)
Yes, this wouldn't solve issues where there are multiple processes accessing a DB, but those could use the current facilities. The above changes could also be a staging post on the way to a full client/server version of SQLite
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
