- From: ben turner <bent.mozilla@gmail.com>
- Date: Wed, 14 Jul 2010 11:35:48 -0400
- 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 UTC