- From: Andrei Popescu <andreip@google.com>
- Date: Thu, 15 Jul 2010 16:30:57 +0100
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Pablo Castro <Pablo.Castro@microsoft.com>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps <public-webapps@w3.org>
On Thu, Jul 15, 2010 at 3:24 PM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Thu, Jul 15, 2010 at 3:09 PM, Andrei Popescu <andreip@google.com> wrote: >> >> On Thu, Jul 15, 2010 at 9:50 AM, Jeremy Orlow <jorlow@chromium.org> wrote: >> >> Nikunj, could you clarify how locking works for the dynamic >> >> transactions proposal that is in the spec draft right now? >> > >> > I'd definitely like to hear what Nikunj originally intended here. >> >> >> >> Hmm, after re-reading the current spec, my understanding is that: >> >> - Scope consists in a set of object stores that the transaction operates >> on. >> - A connection may have zero or one active transactions. >> - There may not be any overlap among the scopes of all active >> transactions (static or dynamic) in a given database. So you cannot >> have two READ_ONLY static transactions operating simultaneously over >> the same object store. >> - The granularity of locking for dynamic transactions is not specified >> (all the spec says about this is "do not acquire locks on any database >> objects now. Locks are obtained as the application attempts to access >> those objects"). >> - Using dynamic transactions can lead to dealocks. >> >> Given the changes in 9975, here's what I think the spec should say for >> now: >> >> - There can be multiple active static transactions, as long as their >> scopes do not overlap, or the overlapping objects are locked in modes >> that are not mutually exclusive. >> - [If we decide to keep dynamic transactions] There can be multiple >> active dynamic transactions. TODO: Decide what to do if they start >> overlapping: >> -- proceed anyway and then fail at commit time in case of >> conflicts. However, I think this would require implementing MVCC, so >> implementations that use SQLite would be in trouble? > > Such implementations could just lock more conservatively (i.e. not allow > other transactions during a dynamic transaction). > Umm, I am not sure how useful dynamic transactions would be in that case...Ben Turner made the same comment earlier in the thread and I agree with him. >> >> -- fail with a specific error. > > To be clear, this means that any async request inside a dynamic transaction > could fail and the developer would need to handle this. Given that we're > already concerned about users handling errors on commit, I'd definitely be > weary of requiring such a thing. But yes, the other option means that > implementations need to either lock more conservatively or be able to > continue on even if they know failure is certain. Agreed. > Btw, is there any reason you talked only about running multiple static or > dynamic transactions at once? As far as I can tell, we should be able to > run multiple at the same time as long as a dynamic transaction always fails > if it tries to access something that a static transaction has locked. Ah, sorry I wasn't clear: you can certainly have multiple static and dynamic at the same time. Thanks, Andrei
Received on Thursday, 15 July 2010 15:31:26 UTC