Re: [sqlite] Understanding table-level locking in shared-cache mode

Oracle's distribution of BerkleyDB with SQLite has page-level locking instead of database-level locking. If you need the increased concurrency that is an option. http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html Supposedly it's a drop-in replacement for sqlite. I

Re: [sqlite] Understanding table-level locking in shared-cache mode

On 7/15/2011 2:15 PM, Steven E. Harris wrote: > I'd like to understand that better so as to figure out whether using > shared-cache mode is appropriate for my application. My motive had been > increased concurrency due to finer-grained locking, but given that this > part of my application is

Re: [sqlite] Understanding table-level locking in shared-cache mode

Igor Tandetnik writes: > All parties in that discussion are mostly wrong. Wonderful. Even though I was hoping they'd turn out to be correct, the actual behavior of my program was not agreeing with them. > Either that, or handle errors that come from

Re: [sqlite] Understanding table-level locking in shared-cache mode

On 7/15/2011 1:30 PM, Steven E. Harris wrote: > , > | In shared-cache mode, is it possible for two different connections > | (both connected to the shared cache) to mutate two different tables at > | the same time? > ` No. > My reading of the documentation[1] on shared-cache mode says

[sqlite] Understanding table-level locking in shared-cache mode

I'll start with my question, the add detail about the environment and scenario motivating it: , | In shared-cache mode, is it possible for two different connections | (both connected to the shared cache) to mutate two different tables at | the same time? ` My reading of the