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

[whatwg] Comments on updated SQL API

From: Brady Eidson <beidson@apple.com>
Date: Wed, 17 Oct 2007 12:46:40 -0700
Message-ID: <E93154F4-A052-4CD8-A2B4-ADA51924EED2@apple.com>

On Oct 17, 2007, at 11:49 AM, Maciej Stachowiak wrote:
>>> Downsides to this approach:
>>>
>>> - You could only have one transaction in flight at once, so you'd  
>>> have to do scheduling in the app code if a transaction-starting UI  
>>> operation happens while you already have a transaction in  
>>> progress. Otherwise multiple transactions would get scrambled. (Or  
>>> else the API layer could parse your statements and understand when  
>>> you have opened a transaction to still implicitly assign  
>>> statements in your callbacks to the transaction, but I am not sure  
>>> this is a simplification overall.)
>>>
>>> - An author mistake (like doing something that causes an exception  
>>> in the callback) means a stuck lock, quite possibly ruining the  
>>> whole session.
>>
>> I agree these are potential downfalls, but ones that already exist  
>> with the current spec.  We have the implicit transaction already,  
>> so a performance-minded developer starting their own transaction  
>> might already trigger this scenario
>
> I don't think you would typically need to use BEGIN, COMMIT or  
> ROLLBACK with the current API, but perhaps the spec should define  
> what happens if you do. In any case, using the easiest path to  
> transactions would not have either of these pitfalls.


There is a problem that has been alluded too in this thread but not  
explicitly called out.

For all the tracking of implicit transactions, having "active thread  
global transactions" in an executeSql() chain, and have  
changeVersion() wait until all transactions are closed... how do we  
handle web developers who start their own transactions?

The user agent can keep track the implicit transactions it manages,  
but a developer throwing a rogue "BEGIN TRANSACTION;" into the mix can  
throw this all off.  Especially in the context of changeVersion()  
which is supposed to be an explicit guarantee of the version change.

Is there some detail/assumption that has been made that I am missing  
which makes this a non-issue?

~Brady
Received on Wednesday, 17 October 2007 12:46:40 UTC

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