Re: [IndexedDB] Current editor's draft

On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>
> 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.

So dynamic transactions, as defined in your proposal, didn't lock on a
whole-objectStore level? If so, how does the author specify which rows
are locked? And why is then openObjectStore a asynchronous operation
that could possibly fail, since at the time when openObjectStore is
called, the implementation doesn't know which rows are going to be
accessed and so can't determine if a deadlock is occurring? And is it
only possible to lock existing rows, or can you prevent new records
from being created? And is it possible to only use read-locking for
some rows, but write-locking for others, in the same objectStore?

/ Jonas

Received on Thursday, 22 July 2010 18:28:05 UTC