Re: [webdatabase] Transaction Locks
On Mon, 31 Aug 2009, Lachlan Hunt wrote: In the processing model, 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. This seems to have been clarified. Can you confirm that you concern is addressed? 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? It's fine, especially for the asynchronous API. (It's black-box indistinguishable from what the spec describes.) On Mon, 31 Aug 2009, Dumitru Daniliuc wrote: 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. The only case where I think a timeout is likely to be needed is when you have two nested synchronous write transactions in a worker. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webdatabase] Transaction Locks
+ 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.h...@lachy.id.auwrote: 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/
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.h...@lachy.id.auwrote: 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/
[webdatabase] Transaction Locks
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/
Re: [webdatabase] Transaction Locks
1. Open a new SQL transaction to the database, and create a SQLTransactionhttp://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 SQLTransactionhttp://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.h...@lachy.id.auwrote: 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/
