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. `._.-(,_..'--(,_..'`-.;.'
