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] -----------------------------------------------------------------------------
