How about the case of:
BEGIN sets 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 SELECTs
INSERT tries to promote shared lock to exclusive on thread one
but fails because second thread holds a shared lock
My understanding is that once a reserved lock has been promoted to
shared, a further reserved lock can be set. That opens the possibility
that the concurrent transactions can conflict when they try to each set
a write lock.
The strategy which increases concurrency does have consequences.
Igor Tandetnik wrote:
John Stanton <[EMAIL PROTECTED]> wrote:
Igor, I confused the issue with names. The correct name is a
"reserved" lock, created when a simple transaction is launched in
"deferred"
mode. Here is the Sqlite explanation.
A BEGIN IMMEDIATE or EXCLUSIVE will acquire a write lock immediately.
Yes. And that may fail with SQLITE_BUSY. But once it succeeds,
subsequent SELECT statements will always succeed, too.
How does your observation help prove the point that every single
sqlite3_step call may return SQLITE_BUSY? This is the only claim of
yours I'm arguing against.
Igor Tandetnik
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
