W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [WebStorage] Concerns on spec section 'Processing Model'

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Fri, 24 Jul 2009 16:45:50 -0700
Cc: Ian Hickson <ian@hixie.ch>, public-webapps WG <public-webapps@w3.org>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>
Message-Id: <DAC4FA02-4002-49A8-A6D3-0EDFCBC2B331@oracle.com>
To: Aaron Boodman <aa@google.com>

On Jul 24, 2009, at 4:25 PM, Aaron Boodman wrote:

> On Fri, Jul 24, 2009 at 4:12 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com 
> > wrote:
>> On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
>>>> 2. create single-instance-only apps , i.e., hold a write lock on  
>>>> the
>>>> database forever since they don't want to deal version checks.
>>> I don't think you understand the spec - it isn't actually possible  
>>> to
>>> hold the lock forever.
>> It is a little insulting for you to say that, but I will not take  
>> offense to
>> it.
> I didn't mean any offense, I really don't think you understand the
> spec completely :).

I beg to differ. Au contraire, I really don't think you understand  
databases at all.

>>> Locks aren't an explit part of the API, but are
>>> implicit and released automatically when functions return.

This is completely incorrect. Read below for more details.

>>> Take a look at the transaction method again:
>>> db.transaction(function(tx) {
>>>  tx.executeSql(strSql, function() {
>>>  });
>>> });
>>> The transaction is implicitly released when the last sql statement  
>>> is
>>> completed (or fails). The only way you can keep this transaction  
>>> open
>>> is to execute more SQL.
>> (corrected a slight typo in the example - it was missing the  
>> parameter
>> definition for tx)
> Thanks for the correction. Code is for conversational purposes only. I
> also may be forgetting some API details since I haven't looked at this
> in awhile.
>> If I put in a timer or another asynchronous call inside the block  
>> and that
>> block used the variable tx, wouldn't it force the implementation to  
>> continue
>> holding the database lock? If so, there is no limit to how long I  
>> can hold
>> on to variables, and hence I could hold on to the database as an  
>> exclusive
>> reader/writer for as long as I wanted to. A novice programmer would  
>> probably
>> not even understand what a transaction means, except that they need a
>> "handle" to change stuff. That programmer could hold on to this  
>> handle for
>> the duration of the session.
> No. The transaction is not closed on GC, it is closed when the last
> statement that is part of the transaction completes. So holding a
> reference to the tx variable does nothing one way or the other. The
> only way to hang the transaction open would be to execute statements
> over and over.

A transaction is not complete until I either commit or rollback the  
transaction, which I can choose to do as late as I want to, e.g., at  
window.onclose. Therefore locks on the database will not be released  
for as long as the application wants to hold on to the transaction.

> On Fri, Jul 24, 2009 at 4:13 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com 
> > wrote:
>> On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
>>> So you are
>>> reduced to very awkward ways of cooperating -- using the database
>>> itself as a queue or for master election, or designing a separate
>>> transaction system between tabs which might be on separate threads,
>>> using an asynchronous API. Or you just accept that any statement can
>>> fail and retry everything. Or your app is just buggy if multiple
>>> instances are open.
>> Did you consider for a moment that all this is merely a result of  
>> the SQLite
>> "feature" to lock the entire database?
> No, having the database not be able to change out from under a
> multi-step update was a design goal of the API. Implementing a complex
> application without exclusive transactions would be very difficult.

I am not proposing to take away your choice. But please don't take  
away mine.

It would be useful to see an explanation as to why the proposal I made
add an isolation level parameter with a default value of SERIALIZABLE  
and remove the exclusive database-level write lock requirement

is worse than the current spec text. You can refer to SQL92 explain  
the meaning of SERIALIZABLE. AFAIK, there are no interoperability  
problems with transaction isolation levels.

Received on Friday, 24 July 2009 23:48:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC