Re: [webdatabase] Transaction Locks

I can't speak for the spec authors, but I can tell you what WebKit does at
the moment. We acquire a lock before we run the transaction callback, but
just like you, we do not have a timeout that invokes the error callback. So
it seems to me like overall our implementations should behave similarly (we
wait for the lock before running the transaction callback, you wait for it
before running the first statement).

1. Is it OK to start a transaction callback without getting a lock first? I
don't see why not, as long as the transaction produces the correct result.
2. Do we need to have a timeout on acquiring locks (or anything else, for
that matter) when opening transactions? I don't think so. As a user, I'd
rather have a "sometimes slow" web page than a "sometimes failing" one.

dumi


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