Thanks for the reply Bela. My confusion is related to the case where the node doesn't exist. I have since concluded that since there is no node, there is nothing to lock, and so the best approach is to always make sure the node exists before trying to examine it.
In my testing, if I were to change line 6 to be a get() instead of a put(), tx2 would see the value committed by tx1 (for tx2, the gets on line 3 and 6 produce different results) - doesn't that violate the REPEATABLE_READ semantics? Would it be safe to say that the locking semantics within a transaction only apply if the node exist at the start of the transaction? Thanks, -- dave View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3895823#3895823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3895823 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
