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

[webdatabase] Transaction Locks

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Mon, 31 Aug 2009 13:37:53 +0200
Message-ID: <4A9BB611.1090805@lachy.id.au>
To: public-webapps <public-webapps@w3.org>
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 Monday, 31 August 2009 11:38:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT