Question

CAVEAT: I ran into this problem a few years ago. I forget the actual problem I was trying to solve so I have substituted it with a theoretical problem involving a linked list.

---

I’ve been trying to use READ_COMMITTED transaction isolation level for over a year now and I’m getting very frustrated with the bugs resulting from my lack of experience. I would appreciate it if you guys could give me a head’s up as to what I am missing here.

Pretty much all application logic I implement cannot be expressed in terms of a single SQL query. That is, I almost always end up having to walk the object graph. Inevitably I run into inconsistent state from within the same transaction. For example, imagine you store a singly-linked list in the database and you want to find out whether the list contains a loop (described in greater detail below). I can’t think of any way to do this under READ_COMMITTED because the outbound references could be updated from underneath my feet as I walk the graph. I can only see READ_COMMITTED working is for queries which can be represented using a single SQL statement.

• The database schema is Node[id, name, next_id]

• Initially the database contains: A -> B -> C -> A

  1. Thread 1 reads: A -> B, B -> C
  2. Thread 2 updates the database to: D -> B -> C -> D
  3. Thread 1 reads: C -> D
  4. Thread 1 detects no loop although one should have been detected. From Thread 1’s point of view it read: A -> B -> C -> D but it should have detected one of the following loops:

A -> B -> C -> A or
D -> B -> C -> D

Answer 1

Answer courtesy of Michal Bergmann: http://groups.google.com/group/h2-database/browse_frm/thread/8f253177e2b6c543?tvc=1

READ_COMMITTED_SNAPSHOT isolation level can help you to solve problem
with concurrent operations. It allows to performing multiple queries
without being affected by other simultaneous transactions.

You could also

• copy data to temporary table first
• lock the table and prevent updates
• monitor table for changes (with a trigger) and if it does change
  during loop detection, your result may not be valid, then you can
  throw it away and repeat loop detection.
• use application logic to postpone any changes till loop detection is
  finished

Using READ_COMMITTED_SNAPSHOT isolation level is probably the best
solution, if database supports it. It has low overhead and doesn’t
block concurrent transactions.