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

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 :).

>> Locks aren't an explit part of the API, but are
>> implicit and released automatically when functions return.
>>
>> 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.


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 do understand that your position that there is a tradeoff: you give
up some performance because a skilled developer could do finer grained
locking and get better concurrency. And I think you are arguing that
there should be an option for non-exclusive write transactions, or at
least it should be up to the UA.

I still feel that with the number of clients a typical HTML5 database
will have, this is a non-issue and the spec makes the correct
tradeoff.

- a

Received on Friday, 24 July 2009 23:25:56 UTC