- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 27 Jul 2010 08:38:28 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Nikunj Mehta <nikunj@o-micron.com>, Pablo Castro <Pablo.Castro@microsoft.com>, Andrei Popescu <andreip@google.com>, public-webapps <public-webapps@w3.org>
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. >> >> >> 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 :) / Jonas
Received on Tuesday, 27 July 2010 15:39:24 UTC