Re: [IndexedDB] Current editor's draft

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