W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [webdatabase] Transaction Locks

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 26 Nov 2009 01:29:02 +0000 (UTC)
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Dumitru Daniliuc <dumi@chromium.org>, Michael Nordman <michaeln@google.com>
Cc: public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0911260120440.10133@hixie.dreamhostps.com>
On Mon, 31 Aug 2009, Lachlan Hunt wrote:
> In the processing model, step 2 says:
>   "If an error occurred in the opening of the transaction (e.g. if the
>    user agent failed to obtain an appropriate lock after an appropriate
>    delay), jump to the last step."
> It's not clear if the spec requires the transaction to fail to open in 
> the case that it can't yet obtain an appropriate lock, or whether the 
> spec just allows that as an implementation decision.

This seems to have been clarified. Can you confirm that you concern is 

> According to our developer, the way we've implemented it is that we will 
> always create a new transaction and run the transaction callback, but 
> the SQL statements themselves will be queued up and run whenever the 
> lock becomes available.  There is no timeout that will cause it to 
> invoke the error callback.
> Is this acceptable, or should the transaction callback not be run while 
> there is another lock in effect on the database?

It's fine, especially for the asynchronous API. (It's black-box 
indistinguishable from what the spec describes.)

On Mon, 31 Aug 2009, Dumitru Daniliuc wrote:
> I can't speak for the spec authors, but I can tell you what WebKit does 
> at the moment. We acquire a lock before we run the transaction callback, 
> but just like you, we do not have a timeout that invokes the error 
> callback. So it seems to me like overall our implementations should 
> behave similarly (we wait for the lock before running the transaction 
> callback, you wait for it before running the first statement).
> 1. Is it OK to start a transaction callback without getting a lock 
> first? I don't see why not, as long as the transaction produces the 
> correct result.
> 2. Do we need to have a timeout on acquiring locks (or anything else, 
> for that matter) when opening transactions? I don't think so. As a user, 
> I'd rather have a "sometimes slow" web page than a "sometimes failing" 
> one.

The only case where I think a timeout is likely to be needed is when you 
have two nested synchronous write transactions in a worker.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 26 November 2009 01:29:33 UTC

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