- From: Aaron Boodman <aa@google.com>
- Date: Mon, 3 Aug 2009 10:58:38 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
On Mon, Aug 3, 2009 at 3:36 AM, Ian Hickson<ian@hixie.ch> wrote: > > On Mon, 27 Jul 2009, Aaron Boodman wrote: >> >> On the subject of the callbacks, you should note that only having the >> sync API in workers won't fix this. The callbacks are a natural result >> of the requirement to never leave transactions open. >> >> The current sync proposal's explicit commit/rollback methods are a >> bug, not a feature. They should be changed, so that the usage is along >> the lines of: >> >> database.syncTransaction(function(tx) { // This callback is >> re-entrant for JS point of view >> var result = database.executeSQL(statement, args); // executeSQL is >> synchronous rather than async inside sync transactions >> }); >> >> So it would get rid of the statement callbacks, but not the transaction one. > > The API was intentionally made more obviously synchronous to avoid having > to make people use callbacks. > > Would making all transactions automatically rollback if not committed when > the event loop spins be an acceptable substitute solution? A few problems with this: - In the case of workers, it could be more common for a single event loop entry to last a very long time. So closing the transaction on event loop exit could effectively mean "never". - It is likely to lead to difficult to debug issues. In the common path, developers will close transactions because they will notice incorrect code during development. It is only in the error cases that they will forget to close the transactions. So every so often, you'll get errors or hung workers (depending on what the behavior is spec'd to be when you open a sync transaction while another is open in the same worker), and no good way to track down the transaction that was left open. In my experience with Gears, to avoid these issues, the very first thing developers did was write a wrapper around the Gears API that worked the way I'm suggesting. I also don't see what not having a callback buys. I'm not sure if you noticed, but I was suggesting that the callback be reentrant. So if you do this: var theResult = null; database.syncTransaction(function(tx) { theResult = tx.executeSQL("select * from ...").rows[0].val; }); alert(theResult); It will do the right thing. Are you concerned that developers won't realize that the callback is reentrant and will invest more effort writing their code in an asynchronous style? - a
Received on Monday, 3 August 2009 17:59:18 UTC