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.
"...In SQLite version 3.0.8 and later, transactions can be deferred,
immediate, or exclusive. Deferred means that no locks are acquired on
the database until the database is first accessed. Thus with a deferred
transaction, the BEGIN statement itself does nothing. Locks are not
acquired until the first read or write operation...".
That means a simple BEGIN is basically a no-op and the transaction does
not start in earnest until the first serious SQL statement is executed,
at which time the lock is promoted from RESERVED to be either a READ or
a WRITE lock (shared or exclusive).
A BEGIN IMMEDIATE or EXCLUSIVE will acquire a write lock immediately.
In our threaded applications we disable the Sqlite locking and use
pthread rwlocks to encapsulate transactions. We lose some possible
concurrency by not having the deferred mode but gain by not having the
overhead of the POSIX file locks and we can never get a BUSY so avoid
that logic in the application. We avoid the ugliness and cycle stealing
of polling-type waits, the feared and loathed "busy wait".
Igor Tandetnik wrote:
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]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
