[whatwg] SQL API error handling

[Maciej Stachowiak]

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