- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 22 Jul 2010 11:27:16 -0700
- To: Nikunj Mehta <nikunj@o-micron.com>
- Cc: Pablo Castro <Pablo.Castro@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>, Andrei Popescu <andreip@google.com>, public-webapps <public-webapps@w3.org>
On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta <nikunj@o-micron.com> wrote: > > On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote: > >> >> From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy Orlow >> Sent: Thursday, July 15, 2010 8:41 AM >> >> On Thu, Jul 15, 2010 at 4:30 PM, Andrei Popescu <andreip@google.com> wrote: >> 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. >>>> >>>> Yes, dynamic transactions would not be useful on those implementations, but the point is that you could still implement the spec without a MVCC backend--though it would limit the concurrency that's possible. Thus "implementations that use SQLite would" NOT necessarily "be in trouble". >> >> Interesting, I'm glad this conversation came up so we can sync up on assumptions...mine where: >> - There can be multiple transactions of any kind active against a given database session (see note below) >> - Multiple static transactions may overlap as long as they have compatible modes, which in practice means they are all READ_ONLY >> - Dynamic transactions have arbitrary granularity for scope (implementation specific, down to row-level locking/scope) > > Dynamic transactions should be able to lock as little as necessary and as late as required. So dynamic transactions, as defined in your proposal, didn't lock on a whole-objectStore level? If so, how does the author specify which rows are locked? And why is then openObjectStore a asynchronous operation that could possibly fail, since at the time when openObjectStore is called, the implementation doesn't know which rows are going to be accessed and so can't determine if a deadlock is occurring? And is it only possible to lock existing rows, or can you prevent new records from being created? And is it possible to only use read-locking for some rows, but write-locking for others, in the same objectStore? / Jonas
Received on Thursday, 22 July 2010 18:28:05 UTC