Using repeatable read as transaction isolation will not stop concurrent read access to the node if i'm not mistaken. My interpretation is that atijms want to get an exclusive lock on '/a/b/n1' regardless of read or write operation. If this is correct then repeatable_read would not solve the issue. I have actually the same requirement, I need to access a node and lock that node (and that node only) excusively. I do not want to write-lock the parent nodes. If I use Option.setForceWriteLock() , then all nodes are write locked. So far, I have found two working solutions, none which are pretty imho. 1. Perform a write operation such as remove(...) first when accessing the node. That acquires a write lock during the transaction right away. Not very performance wise I would gather though =) 2. Make your own locking scheme. I implemented this, it doesn't feel right (feels like a true hack), but it works for me. First I get the lock from the node, add the lock to my transaction. Then I acquireAll on the node for read locks and finally acquire write lock on the leaf node only. I'd be real happy if there was an option we could provide (similar to Options.setForceWriteLock()) that let us readlock the branch and write lock the leaf node only... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4050321#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...