W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] Current editor's draft

From: Nikunj Mehta <nikunj@o-micron.com>
Date: Thu, 22 Jul 2010 18:43:13 +0800
Cc: Jeremy Orlow <jorlow@chromium.org>, Andrei Popescu <andreip@google.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>
Message-Id: <07C97BF7-046B-42B6-A146-347EAD023B4D@o-micron.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>

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.

> - 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
Received on Thursday, 22 July 2010 16:55:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC