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.
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.
>
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
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
4 matches
Mail list logo