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
