Martin Alfredsson <[EMAIL PROTECTED]> wrote:
My problem is that the SHARED lock does not stay after _step() returns
SQLITE_DONE and that this allows another process to update the
database and I end up with a locked database.
Why exactly is this a bad thing? When sqlite3_step returns SQLITE_DONE,
the processing of SELECT statement is complete. You are no longer
reading, so what's wrong with allowing somebody else to write?
Sample;
------------------------------------------------------------------------
sqlite3_prepare()
<=== CORRECT, Another process tries to write, but the db is locked
<=== SHARED lock is on
Actually, the SHARED lock should be acquired on the first sqlite3_step,
not on sqlite3_prepare. A prepared statement may be kept around, unused,
for a long time. You don't want to keep the database locked all this
time.
If a write occurs in the third position the database get locked until
the process that did the write is terminated.
Surely you mean "until the process completes its write operation".
Igor Tandetnik
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
