+ 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 <lachlan.hunt@lachy.id.au>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/
>
>