Re: [IndexedDB] Current editor's draft

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".


> >>
> >>   -- 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
>