Re: [sqlite] Re: Re: Re: SQLite3 Concurrency

2007-08-26 Thread John Stanton
Travor, absolutely correct. my apology for misleading everyone. Trevor Talbot wrote: You're confused about the locking; see http://sqlite.org/lockingv3.html On 8/26/07, John Stanton <[EMAIL PROTECTED]> wrote: How about the case of: BEGINsets reserved lock on thread one No lock.

Re: [sqlite] Re: Re: Re: SQLite3 Concurrency

2007-08-26 Thread Trevor Talbot
You're confused about the locking; see http://sqlite.org/lockingv3.html On 8/26/07, John Stanton <[EMAIL PROTECTED]> wrote: > How about the case of: > BEGINsets reserved lock on thread one No lock. > SELECT promotes lock to shared on thread one Thread one acquires SHARED lock. >

Re: [sqlite] Re: Re: Re: SQLite3 Concurrency

2007-08-26 Thread John Stanton
Based on the description quoted by Igor-2 the situation below would not occur because the reserved lock is not set until the INSERT is intercepted. Since there can be only one reserved lock current, a busy can occur at that point. As I recall that logic counteracts write starvation by

Re: [sqlite] Re: Re: Re: SQLite3 Concurrency

2007-08-26 Thread John Stanton
How about the case of: BEGINsets reserved lock on thread one SELECT promotes lock to shared on thread one BEGIN sets reserved lock from thread two SELECT promotes reserved lock in thread two to shared ...at this point two threads are simultaneously processing