I have solved this problem by writing a wrappers around sql_exec and sql_query, sql_step, etc... In these wrappers I handle the waiting for busy and the lock file issue...
It is not elegant but it allowed me to preserve the interface the same way without having to do it at the application level. Tezozomoc. ----- Original Message ----- From: "Dave Hayden" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 11, 2004 3:48 PM Subject: Re: [sqlite] Deadlock when doing threaded updates and inserts > On Aug 11, 2004, at 6:49 AM, D. Richard Hipp wrote: > > > Oops. The db1 should do a ROLLBACK, not a COMMIT. Or db2 can > > do an END TRANSACTION (since it never made any changes) and allow > > db1 to complete instead. The point is that when two threads or > > processes are trying to write at the same time, one of the two > > must back off, abandon their transaction (using ROLLBACK) and let > > the other proceed. > > Wow. That adds a whole lot of complexity to my code. Every transaction > would be inside a loop that checks for a busy return from any statement > within. And most of the places I'm using a transaction, I'm doing a few > hundred inserts or updates from a number of different functions. > > This really is something I'd expect to run under the hood. Since only > one of the competing threads will have completed a write (right?), > can't the others "postpone" their transactions somehow until they can > get a write lock? > > For now, I've solved the problem by adding my own locks to exclude > simultaneous transactions on the same database file. I'm only using > transactions for writes (is there any reason for a read-only > transaction?) so if there's no way to resolve two opened write > transactions, you shouldn't be able to open two in the first place. > > Please let me know if there's something I'm missing here.. > > Thanks, > -Dave > >
