- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Fri, 24 Jul 2009 16:12:00 -0700
- To: Aaron Boodman <aa@google.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-webapps WG <public-webapps@w3.org>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>
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.
> 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)
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.
Nikunj
http://o-micron.blogspot.com
Received on Friday, 24 July 2009 23:14:32 UTC