+ Dumi who's working on this for Chromium and has dealt with some of these issues recently, IIRC.
On Mon, Aug 31, 2009 at 4:37 AM, Lachlan Hunt <[email protected]>wrote: > Hi, > In the processing model [1], 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. > > 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? > > [1] http://dev.w3.org/html5/webdatabase/#processing-model > > -- > Lachlan Hunt - Opera Software > http://lachy.id.au/ > http://www.opera.com/ > >
