- 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>
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 addressed? > 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