Re: [IndexedDB] Current editor's draft

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.

>>
>>   -- fail with a specific error.
>
> To be clear, this means that any async request inside a dynamic transaction
> could fail and the developer would need to handle this.  Given that we're
> already concerned about users handling errors on commit, I'd definitely be
> weary of requiring such a thing.  But yes, the other option means that
> implementations need to either lock more conservatively or be able to
> continue on even if they know failure is certain.

Agreed.

> Btw, is there any reason you talked only about running multiple static or
> dynamic transactions at once?  As far as I can tell, we should be able to
> run multiple at the same time as long as a dynamic transaction always fails
> if it tries to access something that a static transaction has locked.

Ah, sorry I wasn't clear: you can certainly have multiple static and
dynamic at the same time.

Thanks,
Andrei

Received on Thursday, 15 July 2010 15:31:26 UTC