I use a wrapper that accepts a string of one or more SQL statements. I scan through the string looking for "INSERT", "UPDATE" or "DELETE". If I see any of those values, I start the whole thing with a "BEGIN IMMEDIATE;". If none are found I assume it is a SELECT (read only) and start with a "BEGIN;".
This solved all of my dead-lock issues and allows multiple readers. If there is a better way (that could work in a generic wrapper) I'd be happy to hear about it. On 8/10/06, Eric van der Maarel <[EMAIL PROTECTED]> wrote: > > > John Stanton wrote: > > Why not make your application simple and use a mutex to synchronize > > your threads and serialize the database access? > Well, I figure, if the db has an advanced locking/synchronization > mechanism (that even makes a distinction between reads and writes), > using that will actually make my application easier since in general I > don't know which threads read and/or write. In the case of sqlite I > can do multi-threaded reads that don't lock at all. You may want to surround your sqlite calls with reader-writer locks, in that case. > > > > [EMAIL PROTECTED] wrote: > >> I have two threads heavily writing to the db. Hence, I get some > >> SQLITE_BUSY return values. > >> > >> If I get it from sqlite3_step(), I wait a few ms and call > >> sqlite3_step() again etc. This happens in one thread, thread A. > >> > >> The other thread (thread B) however, is calling the registered busy > >> handler while executing a commit with an sqlite3_exec() call. And > >> this is not going away either. even if I let thread A wait forever > >> (so don't do anything there) thread B is getting SQLITE_BUSY (in > >> commit with sqlite3_exec()). Both threads are not progressing any more... > >> Of course, both pieces of code run fine single-threaded :-) > >> > >> Btw sqlite does not detect it is going into a deadlock since I > >> added a log indicating this in sqlite3BtreeBeginTrans() when it > >> returns SQLITE_BUSY without calling the handler, and this log is > >> never appears. > >> > >> So, I realy don't understand why thread B is calling the busy > >> handler and that the lock is never going away. > >> And is the procedure in thread A correct: just wait and recall the > >> sqlite3_step(). Maybe this is the reason of the behaviour we see in > >> thread B? How to overcome that situation then? > >> > >> Eric > >> > > > > > > > > -- > ------------------------------------------- > | Eric van der Maarel | > | [EMAIL PROTECTED] | > -------------------------------------------^[ZZ > -- Cory Nelson http://www.int64.org To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
