Re: [webdatabase] Transaction Locks

   1.

   Open a new SQL transaction to the database, and create a
SQLTransaction<http://dev.w3.org/html5/webdatabase/#sqltransaction>
object
   that represents that transaction. If the *mode* is read/write, the
   transaction must have an exclusive write lock over the entire database. If
   the *mode* is read-only, the transaction must have a shared read lock
   over the entire database. The user agent should wait for an appropriate lock
   to be available.
   2.

   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.
   3.

   If a *preflight operation* was defined for this instance of the
   transaction steps, run that. If it fails, then jump to the last step. (This
   is basically a hook for the
changeVersion()<http://dev.w3.org/html5/webdatabase/#dom-database-changeversion>
   method.)
   4.

   Queue a task to invoke the *transaction callback* with the
   aforementioned
SQLTransaction<http://dev.w3.org/html5/webdatabase/#sqltransaction>
object
   as its only argument, and wait for that task to be run.

10. (last) Queue a task to invoke the *error callback* with a newly
constructed SQLError <http://dev.w3.org/html5/webdatabase/#sqlerror> object
that represents the last error to have occurred in this transaction.
Rollback the transaction. Any still-pending statements in the transaction
are discarded.

I think its clear what the intent is. A failure to acquire the lock (BEGIN
fails) leads to an error callback w/o having called the transaction
callback. At least thats my reading of it.

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/
>
>