On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote: > > From: jor...@google.com [mailto:jor...@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 <andr...@google.com> wrote: > On Thu, Jul 15, 2010 at 3:24 PM, Jeremy Orlow <jor...@chromium.org> wrote: >> On Thu, Jul 15, 2010 at 3:09 PM, Andrei Popescu <andr...@google.com> wrote: >>> >>> On Thu, Jul 15, 2010 at 9:50 AM, Jeremy Orlow <jor...@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. > - Overlapping between statically and dynamically scoped transactions follows > the same rules as static-static overlaps; they can only overlap on compatible > scopes. The only difference is that dynamic transactions may need to block > mid-flight until it can grab the resources it needs to proceed. This is the intention with the timeout interval and asynchronous nature of the openObjectStore on a dynamic transaction. > > Note: for some databases having multiple transactions active on a single > connection may be an unsupported thing. This could probably be handled in the > IndexedDB layer though by using multiple connections under the covers. > > -pablo >
