Re: [sqlite] shared cache mode locking

2007-12-21 Thread Ken
So did my post. We are talking about the same thing. Definately confusing, at least to me.. The problem exists wherein you have two shared connections and one connection performs a begin exclusive... The other connection was just ignoring the exclusivity lock and continuing on its merry way

Re: [sqlite] shared cache mode locking

2007-12-21 Thread Ed Pasma
No, you did not confuse me. We are talking about different things it appears. My post refers to the shared-cache locking model (http:// sqlite.org/sharedcache.html). The document is clear by itself. What makes it confusing, is that a shared cache instance exist as a single normal connection

Re: [sqlite] shared cache mode locking

2007-12-21 Thread Ken
Ed, Sorry if I confused you, a "Write" lock is really an EXCLUSIVE lock per sqlite documentation. I used the two interchangeably, pardon my error. A begin exclusive indicates the beginning of a transaction, It escalates the database lock to an EXCLUSIVE lock. The begin transaction does not

Re: [sqlite] shared cache mode locking

2007-12-21 Thread Ed Pasma
The ticket has already been resolved, I see. So it has been considered a bug. In my earlier reply I tried to defend the current behavour to be in line with the document, http://sqlite.org/ sharedcache.html. I'm happy to change my mind now. Only I miss something in the model as described in

Re: [sqlite] shared cache mode locking

2007-12-20 Thread Ken
Ed, Dan opened a ticket. I agree the documentation isn't clear on the Exlusive locking state. Not really sure, if this is by design or a bug at this stage. I do think its a great feature of the Shared cache mode to allow table level locking. But I'm curious with this table level locking what

Re: [sqlite] shared cache mode locking

2007-12-20 Thread Ed Pasma
Hello,` Empirically I found that it is exactly true. Must admit I'm confused but may it is in line with the Shared-Cache locking model. This does not mention the EXCLUSIVE locking state. The most 'secure' locking state it mentions is a write-transaction and this can coexist with

Re: [sqlite] shared cache mode locking

2007-12-19 Thread Ken
Some additional info: when the sqlite_lock is returned there is another thread that appears to be reading the same table. Does the sqlite3 step return sqlite_locked in this case? Thanks, Ken Ken <[EMAIL PROTECTED]> wrote: While using the new 3.5.4 sqlite3_enable_shared_cache I ran into a

[sqlite] shared cache mode locking

2007-12-19 Thread Ken
While using the new 3.5.4 sqlite3_enable_shared_cache I ran into a strange lock situation. SQLITE_LOCK is returned from an insert statement, even though the thread/connection performed a successful "begin exclusive" transaction. begin exclusive insert into