>>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?
>
It would be no problem unless the the database stays locked (read below).
>> 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.
OK, you are probably right there.
>> 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".
I wish, but no, the database is locked until the process that writes is
terminated. It has nothing to do with if that process writes or reads
and I checked all return codes. I have even done a simple testcase that
shows this.
/Martin
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
