John Stanton <[EMAIL PROTECTED]> wrote:
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?
I'm not sure I understand your question. http://sqlite.org/lockingv3.html says that a simple BEGIN statement doesn't acquire any locks at all:
"Note that the BEGIN command does not acquire any locks on the database. After a BEGIN command, a SHARED lock will be acquired when the first SELECT statement is executed. A RESERVED lock will be acquired when the first INSERT, UPDATE, or DELETE statement is executed."
Are you perhaps thinking of BEGIN IMMEDIATE or BEGIN EXCLUSIVE? What exactly do you mean by "deferred lock"?
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.
But not between two sqlite3_step's for the same SELECT statement, which is what you appear to have claimed.
Igor Tandetnik
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
