Re: [IndexedDB] Current editor's draft

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


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

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.
 (Which gets us back to the same 2 scenarios that you were asking about for
dynamic transactions).

J