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) - 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. 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
