From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, July 22, 2010 5:30 PM
>> On Thu, Jul 22, 2010 at 5:26 PM, Pablo Castro >> <pablo.cas...@microsoft.com> wrote: >> > >> > From: Jonas Sicking [mailto:jo...@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. That's right, calls would block if they need to acquire a lock for a key or a range and there is an incompatible lock present that overlaps somehow with that. -pablo
