How about the case of a simple BEGIN which sets a deferred lock so that
the busy will occur when that lock is promoted later in the the transaction?
As I understand it the deferred lock capability is conducive to better
concurrency, but does have other effects requiring that provision be
made to intercept a BUSY in the body of the transaction.
Forcing the BEGIN to be exclusive would certainly mean that only the
BEGIN step could return a BUSY.
Igor Tandetnik wrote:
John Stanton <[EMAIL PROTECTED]> wrote:
You need to be prepared to get a busy status after each Sqlite3_step.
Not really. Only the very first sqlite3_step after a prepare or reset
can get SQLITE_BUSY. If it succeeds, the connection has acquired a
SHARED lock and subsequent steps are guaranteed not to run into
concurrency problems.
Igor Tandetnik
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
