On Thu, Jul 22, 2010 at 5:26 PM, Pablo Castro <[email protected]> wrote: > > From: Jonas Sicking [mailto:[email protected]] > 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
