Re: SQLite Concurrency Issue

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" <[email protected]> 
12/22/2010 06:45 PM

To
<[email protected]>
cc
DBI Users Mailing List <[email protected]>
Subject
Re: SQLite Concurrency Issue






On Dec 22, 2010, at 3:30 PM, <[email protected]> 
<[email protected]> 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.