"D. Richard Hipp" <[EMAIL PROTECTED]> writes: > Tito Ciuro wrote: >> I'm definitely not happy about this... >> Let me get this right... it seems that you're cruising along fine with >> SQLITE_OK's all over the place when suddenly one of your threads/processes >> get a SQLITE_BUSY signal in the middle of a transaction. In order to solve >> the crisis, one of the transactions *must* be rolled back: >> Questions: >> 1) Which one? Do I toss a coin? > > Rollback the one that returned SQLITE_BUSY
In the earlier examples, multiple threads each received an SQLITE_BUSY indication. If they both (all) rollback and retry, the deadlock condition will likely recur... I'm currently encountering the reader starvation problem in 2.8.x, and am eager to switch to 3.0 to solve it, but this rollback/retry issue has me waiting on switching. I will need to do a fair amount of redesign work to accommodate this procedure due to the nature of the transactions (many operations invoked by a number of functions), unless... > I'll look into adding a PRAGMA that makes BEGIN TRANSACTION acquire > a RESERVED lock immediately. That will reduce the amount of confusion > about this issue, I suppose. Does enabling this PRAGMA regenerate the reader starvation problem of 2.8.x, or is that problem solved elsewise in 3.0? Derrell
