My uses of SQLite are multithreaded (mostly) single process. So, an approach that would appeal to me is "client-server" where the server is a thread in my process, and the clients are other threads. Adding a lock manager to the server thread would permit fine grained locking with ACID properties.
I used the phrase "client-server" above because it is the closest proposed model to what I'd like to see... but in a single process no server is really necessary as long as all the client threads are using a lock manager service appropriately. This approach could be combined with any of the interprocess approaches described on the "Improving Concurrency In SQLite" web page, or with the present coarse grained locking for interprocess access. In other words, run multi-threaded fine grain locking and access within each process, and coordinate between the processes using coarse grained file locks. In fact, given a multi-threaded fine grain locking SQLite, one could choose between using the present coarse locking between processes, or creating an SQLite server process which spawns threads on behalf of incoming inter-process clients. Leave the decision to use (and implementation of) interprocess communication and a server process to users (or someday an optional layer on top of SQLite). As to the semantics of BEGIN, I am strongly in favor of "4.3 Defer write locks by default." This gives the best concurrency for the least effort on the part of the SQL programmer. There is typically little need for early write locking, and as you point out in section 4.3 there is a workaround when it is needed. Some database have a syntax "SELECT FOR UPDATE..." or something like that to grab a write lock early. One approach not mentioned is row (or page or table) versioning. This provides multiple versions of a row to exist simultaneously so writers never block readers and visa versa. It is an elegant approach, but suffers the same drawbacks as Mrs. Brisby's suggestion to hold all updates until transaction COMMIT (optimistic concurrency control). e --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
