Igor - ok I tried this, and now I am getting SQLITE_BUSY returned when I try to sqlite3_exec my "BEGIN IMMEDIATE" statement. So I then put that in a do-while( rc == SQLITE_BUSY) loop, and now my first thread is getting SQLITE_BUSY returned when it tries to execute the 1-line INSERT statement (without transaction).
So I can wrap all these calls in a do-while loop to check for SQLITE_BUSY, but isn't this the point of declaring a busy_handler ?? Why wouldn't the database use the busy-handler in the case where it is trying to execute my 1-line INSERT statement? -Dave On 3/13/06, Igor Tandetnik <[EMAIL PROTECTED]> wrote: > > Dave Brown <[EMAIL PROTECTED]> wrote: > > Hi all - I am seeing a strange problem where I have multiple threads > > trying to both do writes to the database, and one thread gets back an > > immediate SQLITE_BUSY even though *both* have set the busy handler to > > 10 seconds, and the write operation is much much faster than this (on > > the order of milliseconds). > > This happens when the two threads get into a deadlock. A situation is > possible when two threads both start a transaction, then both try to > write, and neither can proceed since the other holds a transaction open. > In this case, waiting is pointless and will only make the situation > worse. The only way out is for one thread to roll back its transaction > and retry from the beginning. > > Open your writer transactions with BEGIN IMMEDIATE to avoid getting into > this situation. > > Igor Tandetnik > >
