Re: [IndexedDB] Current editor's draft

On Thu, Jul 15, 2010 at 9:50 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Thu, Jul 15, 2010 at 2:37 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Wed, Jul 14, 2010 at 6:05 PM, Pablo Castro
>> <Pablo.Castro@microsoft.com> wrote:
>> >
>> > From: Jonas Sicking [mailto:jonas@sicking.cc]
>> > Sent: Wednesday, July 14, 2010 5:43 PM
>> >
>> > On Wed, Jul 14, 2010 at 5:03 PM, Pablo Castro
>> > <Pablo.Castro@microsoft.com> wrote:
>> >>
>> >> From: Jonas Sicking [mailto:jonas@sicking.cc]
>> >> Sent: Wednesday, July 14, 2010 12:07 AM
>> >>
>> >
>> >>> I think what I'm struggling with is how dynamic transactions will help
>> >>> since they are still doing whole-objectStore locking. I'm also curious
>> >>> how you envision people dealing with deadlock hazards. Nikunjs
>> >>> examples in the beginning of this thread simply throw up their hands
>> >>> and report an error if there was a deadlock. That is obviously not
>> >>> good enough for an actual application.
>> >>>
>> >>> So in short, looking forward to an example :)
>> >
>> > I'll try to come up with one, although I doubt the code itself will be
>> > very interesting in this particular case. Not sure what you mean by "they
>> > are still doing whole-objectStore locking". The point of dynamic
>> > transactions is that they *don't* lock the whole store, but instead have the
>> > freedom to choose the granularity (e.g. you could do row-level locking).
>>
>> My understanding is that the currently specced dynamic transactions
>> are still whole-objectStore.
>
> My understanding is that of Pablo's.  I'm not aware of anything in the spec
> that'd limit you to object-store wide locks.  Whats more, if this were true
> then I'd be _very_ against adding dynamic transactions in v1 since they'd
> offer us very little in turn for a lot of complexity.
> This misunderstanding would definitely explain a lot of confusion within our
> discussions though.  :-)
>
>>
>> Once you call openObjectStore and
>> successfully receive the objectStore through the 'success' event, a
>> lock is held on the whole objectStore until the transaction is
>> committed. No other transaction, dynamic or static, can open the
>> objectStore in the meantime.
>>
>> I base this on the sentence: "There MAY not be any overlap among the
>> scopes of all open connections to a given database" from the spec.
>>
>> But I might be misunderstanding things entirely.
>>
>> 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?
   -- fail with a specific error.

Thanks,
Andrei

Received on Thursday, 15 July 2010 14:10:15 UTC