W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] SQL API error handling

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 15 Oct 2007 14:40:33 -0700
Message-ID: <D80D7C40-9980-4220-BA15-2CB2B4EDCAF2@apple.com>

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.

Received on Monday, 15 October 2007 14:40:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC