- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 22 Jul 2010 17:30:18 -0700
- To: Pablo Castro <Pablo.Castro@microsoft.com>
- Cc: Nikunj Mehta <nikunj@o-micron.com>, Jeremy Orlow <jorlow@chromium.org>, Andrei Popescu <andreip@google.com>, public-webapps <public-webapps@w3.org>
On Thu, Jul 22, 2010 at 5:26 PM, Pablo Castro <Pablo.Castro@microsoft.com> wrote: > > From: Jonas Sicking [mailto:jonas@sicking.cc] > Sent: Thursday, July 22, 2010 5:18 PM > >>> > The author doesn't explicitly specify which rows to lock. All rows that you "see" become locked (e.g. through get(), put(), scanning with a cursor, etc.). If you start the transaction as read-only then they'll all have shared locks. If you start the transaction as read-write then we can choose whether the implementation should always attempt to take exclusive locks or if it should take shared locks on read, and attempt to upgrade to an exclusive lock on first write (this affects failure modes a bit). > >>> What counts as "see"? If you iterate using an index-cursor all the >>> rows that have some value between "A" and "B", but another, not yet >>> committed, transaction changes a row such that its value now is >>> between "A" and "B", what happens? > > We need to design something a bit more formal that covers the whole spectrum. As a short answer, assuming we want to have "serializable" as our isolation level, then we'd have a range lock that goes from the start of a cursor to the point you've reached, so if you were to start another cursor you'd be guaranteed the exact same view of the world. In that case it wouldn't be possible for other transaction to insert a row between two rows you scanned through with a cursor. How would you prevent that? Would a call to .modify() or .put() block until the other transaction finishes? With appropriate timeouts on deadlocks of course. / Jonas
Received on Friday, 23 July 2010 00:31:11 UTC