On Tue, Jul 27, 2010 at 4:38 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Tue, Jul 27, 2010 at 3:14 AM, Jeremy Orlow <jor...@chromium.org> wrote: > > On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking <jo...@sicking.cc> > wrote: > >> > >> On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow <jor...@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
