I don't believe a lockfile would be neccesary. The database serves as your lockfile. You simply re-start the transaction or re-issue the last SQL statement until it goes through or you feel like giving up.
However, most RDBMS's will detect "unresolvable" deadlocks and abort a transaction immediately rather than waiting to timeout. The section "Transaction and Database Locking" in the DBD::SQLite manual on CPAN confirms this with: "busy_timeout doesn't help in this case" You say you've set sqlite_use_immediate_transaction but did you set it for just the transactions you've SEEN abort? This attribute may have to be set for ALL transactions including the SELECTS. "David E. Wheeler" <da...@kineticode.com> 12/22/2010 06:45 PM To <ericbamba...@discover.com> cc DBI Users Mailing List <dbi-users@perl.org> Subject Re: SQLite Concurrency Issue On Dec 22, 2010, at 3:30 PM, <ericbamba...@discover.com> <ericbamba...@discover.com> wrote: > Maybe an obvious quesiton, but can you catch SQLITE_BUSY and just loop and > retry in your application code? Is there any reason not to retry after a > second or so? Such application retry logic is pretty standard for > transaction deadlock issues. I guess I could do that, but I'm going to have to do quite a bit of extra work to add the retry stuff. I might be able to use a lockfile, as well. I'm hating both of these solutions. David Please consider the environment before printing this email.
