[jboss-user] [JBoss Cache Users] - Re: Question about lockParentForChildInsertRemove - when to

[bstansberry@jboss.com]

Thanks for the question; I didn't personally work on the MVCC code and the discussions I'd been on didn't specifically discuss handling of children. So, had to chat with Jason Greene and look into the code, both of which are always good. :-)

As you said getChildren(Names) is a read operation, so with MVCC it won't block due to a concurrent write.

If you need to avoid phantom reads with getChildren(Names), i.e. do two reads in the same tx and not have children appear/disappear, you need to use lockParentForChildInsertRemove.  REPEATABLE_READ is implemented by making a copy of the node before writing and storing it in a context object associated with the transaction, and then only inserting that copy into the main tree on tx commit. But the addition/removal of a child is only considered to be a "write" if lockParentForChildInsertRemove=true. If lockParentForChildInsertRemove=false, no copy of the parent is made, so the inserts/removals become visible to other threads as soon as they commit.

This behavior is consistent with the definition of REPEATABLE_READ in the java.sql.Connection javadocs, which says phantom reads can occur with R_R. Database notions never map exactly to a tree structure, but our interpretations have always treated new child nodes as being analogous to new db records returned by a query.

If you do set lockParentForChildInsertRemove=true, concurrent insertions/removals won't occur, but only one will proceed at a time; any others will block until the first completes.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267068#4267068

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267068