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.
[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
