[whatwg] SQL API error handling
mjs at apple.com
Mon Oct 15 14:40:33 PDT 2007
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
>> 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
>> 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.
More information about the whatwg