Re: [IndexedDB] Current editor's draft

On Tue, Jul 27, 2010 at 4:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Jul 27, 2010 at 3:14 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>
> >> On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >> >> >> And is it
> >> >> >> only possible to lock existing rows, or can you prevent new
> records
> >> >> >> from being created?
> >> >> >
> >> >> > There's no way to lock yet to be created rows since until a
> >> >> > transaction
> >> >> > ends, its effects cannot be made visible to other transactions.
> >> >>
> >> >> So if you have an objectStore with auto-incrementing indexes, there
> is
> >> >> the possibility that two dynamic transactions both can add a row to
> >> >> said objectStore at the same time. Both transactions would then add a
> >> >> row with the same autogenerated id (one higher than the highest id in
> >> >> the table). Upon commit, how is this conflict resolved?
> >> >>
> >> >> What if the objectStore didn't use auto-incrementing indexes, but you
> >> >> still had two separate dynamic transactions which both insert a row
> >> >> with the same key. How is the conflict resolved?
> >> >
> >> > I believe a common trick to reconcile this is stipulating that if you
> >> > add
> >> > 1000 "rows" the id's may not necessarily be 1000 sequential numbers.
> >> >  This
> >> > allows transactions to increment the id and leave it incremented even
> if
> >> > the
> >> > transaction fails.  Which also means that other transactions can be
> >> > grabbing
> >> > an ID of their own as well.  And if a transaction fails, well, we've
> >> > wasted
> >> > one possible ID.
> >>
> >> This does not answer the question what happens if two transactions add
> >> the same key value though?
> >
> > If you're using optimistic transactions, whichever commits first
> succeeds.
> >  Not sure with the pessimistic/lock-based implementations.
>
> That doesn't count as serializable, does it? It's not a dead-lock
> hazard, but a race condition where whoever commits last experiences
> dataloss unless properly handling the commit error.
>

If they don't handle commit errors, yes, you would have data loss.  I didn't
realize we were even considering trying to make dynamic transactions work
without the possibility of the commit failing.


> >> >> >> And is it possible to only use read-locking for
> >> >> >> some rows, but write-locking for others, in the same objectStore?
> >> >> >
> >> >> > An implementation could use shared locks for read operations even
> >> >> > though
> >> >> > the object store might have been opened in READ_WRITE mode, and
> later
> >> >> > upgrade the locks if the read data is being modified. However, I am
> >> >> > not keen
> >> >> > to push for this as a specced behavior.
> >> >>
> >> >> What do you mean by "an implementation could"? Is this left
> >> >> intentionally undefined and left up to the implementation? Doesn't
> >> >> that mean that there is significant risk that code could work very
> >> >> well in a conservative implementation, but often cause race
> conditions
> >> >> in a implementation that uses narrower locks? Wouldn't this result in
> >> >> a "race to the bottom" where implementations are forced to eventually
> >> >> use very wide locks in order to work well in websites?
> >> >>
> >> >> In general, there are a lot of details that are unclear in the
> dynamic
> >> >> transactions proposals. I'm also not sure if these things are unclear
> >> >> to me because they are intentionally left undefined, or if you guys
> >> >> just haven't had time yet to define the details?
> >> >>
> >> >> As the spec is now, as an implementor I'd have no idea of how to
> >> >> implement dynamic transactions. And as a user I'd have no idea what
> >> >> level of protection to expect from implementations, nor what
> >> >> strategies to use to avoid bugs.
> >> >>
> >> >> In all the development I've done deadlocks and race conditions are
> >> >> generally unacceptable, and instead strategies are developed that
> >> >> avoids them, such as always grab locks in the same order, and always
> >> >> grab locks when using shared data. I currently have no idea what
> >> >> strategy to recommend in IndexedDB documentation to developers to
> >> >> allow them to avoid race conditions and deadlocks.
> >> >>
> >> >> To get clarity in these questions, I'd *really* *really* like to see
> a
> >> >> more detailed proposal.
> >> >
> >> > I think a detailed proposal would be a good thing (maybe from Pablo or
> >> > Nikunj since they're who are really pushing them at this point), but
> at
> >> > the
> >> > same time, I think you're getting really bogged down in the details,
> >> > Jonas.
> >> > What we should be concerned about and speccing is the behavior the
> user
> >> > sees.  For example, can any operation on data fail due to transient
> >> > issues
> >> > (like deadlocks, serialization issues) or will the implementation
> shield
> >> > web
> >> > developers from this?  And will we guarantee 100% serializable
> >> > semantics?
> >> >  (I strongly believe we should on both counts.)  How things are
> >> > implemented,
> >> > granularity of locks, or even if an implementation uses locks at all
> for
> >> > dynamic transactions should be explicitly out of scope for any spec.
> >> >  After
> >> > all, it's only the behavior users care about.
> >>
> >> If we can guarantee no deadlocks and 100% serializable semantics, then
> >> I agree, it doesn't matter beyond that. However I don't think the
> >> current proposals for dynamic transactions guarantee that. In fact, a
> >> central point of the dynamic transactions proposal seems to be that
> >> the author can grow the lock space dynamically, in an author defined
> >> order. As long as that is the case you can't prevent deadlocks other
> >> than by forbidding multiple concurrent (dynamic) transactions.
> >
> > There has been a lot of talk on list about how you could implement
> dynamic
> > transactions with locks and I agree that I don't see how what's been
> > mentioned can be guaranteed to be serializable and/or not create
> deadlocks.
> >  But my point is: why are we talking about this??  The spec should talk
> > about the semantics and behavior not the underlying engine, right?
> > I think we need to take a BIG step back here and talk about what the
> > behavior should be from the user point of view and leave implementation
> > details to the implementations.  Otherwise we're going to continue
> getting
> > nowhere in this discussion.
> > I guess the best way forward is for Nikunj and/or Pablo to come up with a
> > concrete proposal for the behavior/semantics (leave implementation out of
> > it, please) and then we can discuss the merits of that.  If we can't
> settle
> > on something soon, I suggest we take them out of the spec for the time
> being
> > since what's there is pretty half baked.
>
> That's exactly what I was trying to ask for too :)
>

Sorry, I thought we you talking about a specific implementation proposal.

J