[whatwg] SQL API error handling

[Ian Hickson]

On Mon, 15 Oct 2007, Scott Hess wrote:
> 
> Under SQLite, there are cases where retrying might work, in which case 
> you can retry.  There are other cases where retry will never work, you 
> need to rollback your transaction and start over.  If you don't do so, 
> you can cause a deadlock.  Much of this can be addressed by using BEGIN 
> IMMEDIATE rather than BEGIN DEFERRED (the default for BEGIN). I'm not 
> certain we can address this kind of issue at the level of this API, if 
> multiple connections to the same database are allowed.

See my reply to Maciej below.


> > > * CORRUPT, insofar as the Database API lets you delete databases (it 
> > > doesn't currently, but we've thought of adding that to Gears).
> 
> You may be correct that authors shouldn't be dealing with this. 
> Guaranteeing the integrity of the database at open is prohibitive (you 
> may have to scan the entire database), and no guarantee in practice, so 
> it's possible that you can detect corruption at any arbitrary statement.

Sure, but that problem occurs everywhere. I mean, there's no JS exception 
for "your CPU core just overheated", but we don't guarentee that won't 
happen either. Database corruption will occur either for hardware reasons 
or due to software bugs. Hardware failures could cause all kinds of random 
stuff, including software bugs (through corruption of executables). Having 
an API to handle software bugs seems silly, since if we could assume that 
that API was bug free, why not assume the rest of the API is too. This 
just seems like a case we shouldn't worry about.


> I'm considering two classes of error, here.  One the one hand are 
> statements which are just incorrect, either syntactically or 
> structurally.  They will never execute, your app is broken.  On the 
> other hand are statement which fail, but are otherwise correct.  I think 
> these cases are reasonable to distinguish, but it may be that the author 
> actions for either statement would be identical, making distinguishing 
> them bootless.

Things that will always fail should raise exceptions from the method.

Things that might, but whose failure state is not immediately known, call 
the callback with an errorCode.


> Whoa!  I just realized that there's another group, constraint failures.  
> These are statements which will sometimes succeed, sometimes fail.  As 
> currently spec'ed, it looks like a constraint failure will cause 
> rollback.  This is probably not appropriate, constraint failures are 
> generally expected to be benign and detectable.  Arguing against myself, 
> I've seen plenty of code which just treats any errors from something 
> which allows for a constraint failure as a constraint failure, so maybe 
> this also can be lumped under a single big error code.

Could you elaborate on this? What would code running into this situation 
look like? How should we expose it?


On Mon, 15 Oct 2007, Maciej Stachowiak wrote:
> 
> 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.

Ok, I've added a new error code (4), with the description:

     The statement failed because the transaction's first
     statement was a read-only statement, and a subsequent statement
     in the same transaction tried to modify the database, but the
     transaction failed to obtain a write lock before another
     transaction obtained a write lock and changed a part of the
     database that the former transaction was dependending upon.

Is that what we want?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'