If you do not rely on Posix file locks at all and use a mutex then all
your problems are gone. Sqlite users are always getting their knickers
in a knot using file locking.
Martin Alfredsson wrote:
Sorry, no.
The problem is that BEGIN TRANSACTION or _prepare/_step does
NOT set a SHARED lock when the SELECT statement is run.
I think this is a bug (since the doc says it should) so I have
added a ticket. There is a workaround though but since SQLite
does not support nested transactions it might be hard to use.
/Martin
>From: John Stanton <[EMAIL PROTECTED]>
>Subject: Re: Please help me locking/transaction? logic !
>Newsgroups: gmane.comp.db.sqlite.general
>Date: 2006-09-25 20:32:48 GMT (18 minutes ago)
>Only one thread or process may be writing, but two of them have a lock.
>What I do to make writing efficient and the logic simple is to use a
>mutex to synchronize the writes.
>Martin Alfredsson wrote:
>> Hi !
>>
>> Only one process IS writing at once. The problem is that if
>> the writing is able to happen after _step and before _finalize
>> it locks the database,
>>
>> What my code does:
>> sqlite3_exec(... "BEGIN TRANSACTION" ...)
>> sqlite3_prepare(... "SELECT * FROM A_TABLE" ...)
>> sqlite3_step(...)
>> <============================= Another process does an UPDATE
>> sqlite3_finalize(...)
>> sqlite3_exec(... "COMMIT TRANSACTION" ...)
>>
<snip>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
