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
