RE: [IndexedDB] Current editor's draft

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

Received on Thursday, 15 July 2010 21:42:08 UTC