W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [webdatabase] Transaction Locks

From: Jeremy Orlow <jorlow@google.com>
Date: Mon, 31 Aug 2009 12:06:29 -0700
Message-ID: <5dd9e5c50908311206m378ea81eu233ab49d0ea6d62c@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: public-webapps <public-webapps@w3.org>, Dumitru Daniliuc <dumi@google.com>
+ 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/
Received on Wednesday, 2 September 2009 14:11:56 UTC

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