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

Reply via email to