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

Re: [WebDatabase] Database interface (vs. DatabaseSync interface)

From: Aaron Boodman <aa@google.com>
Date: Mon, 3 Aug 2009 10:58:38 -0700
Message-ID: <278fd46c0908031058x5f4048f4yaf5ecbf765405daf@mail.gmail.com>
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 GMT

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