- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 15 Oct 2007 14:40:33 -0700
On Oct 15, 2007, at 2:07 PM, Ian Hickson wrote: > On Fri, 5 Oct 2007, Scott Hess wrote: >> >> Reviewing SQLite's error list, the things that MAY have utility to >> report more finely might be: >> >> * LOCKED, where you failed because someone else has things locked. >> Presumably if a single thread of control tries to open the same >> database >> via two objects and start two transactions, one of them is going to >> lose. Having a transaction fail for this reason seems materially >> different from having it fail because the SQL was invalid or >> something >> of that nature, because the appropriate response might be to retry. > > Wouldn't we just want the transaction to wait for the lock to go away? With upgradeable read-write locks, this can lead to a deadlock. Consider two transactions that start with a statement that only needs a read lock. They each grab a non-exclusive read lock and proceed in parallel. For each, the second statement of the transaction is a write. Each would like to upgrade its read lock to an exclusive write lock, but neither can because a shared read lock is still held. At least one must fail and roll back to avoid deadlock. Thus, it must be possible for the first write statement in a formerly read-only transaction to fail. Regards, Maciej
Received on Monday, 15 October 2007 14:40:33 UTC