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

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.

Nikunj
http://o-micron.blogspot.com

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