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

Re: [IndexedDB] Current editor's draft

From: ben turner <bent.mozilla@gmail.com>
Date: Wed, 14 Jul 2010 11:35:48 -0400
Message-ID: <AANLkTin-hpPEgto1zYrTqk9rV_tBh7NqG_JAKy91oMjm@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Pablo Castro <Pablo.Castro@microsoft.com>, Andrei Popescu <andreip@google.com>, Nikunj Mehta <nikunj@o-micron.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>
On Wed, Jul 14, 2010 at 3:10 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> For example, with dynamic transactions you can get into live-lock
> situations.

I'm particularly opposed to dynamic transactions for just this reason.
We would clearly have to throw an exception or call the error callback
if we detect livelock. I doubt that most web authors would recognize
the potential hazard, and even if they did I think it would be
extremely difficult for a web author to test such a scenario or write
code to handle it properly. The hardware running the web app and the
browser's transaction scheduling algorithm would of course affect the
frequency of these collisions making proper tests even more difficult.

> If we do leave them in, it
> should definitely be in its own method to make it quite clear that the
> semantics are more complex.

I completely agree.

So, as I've said, I'm very opposed to leaving dynamic transactions in
the spec. However, one thing we could do if everyone really wanted
this feature I guess is to set a limit of only a single dynamic
transaction per database at a time. That would remove the livelock
hazard but it may diminish the utility of the feature enough to be
useless.
Received on Wednesday, 14 July 2010 15:36:25 GMT

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