"mircea.markus" wrote : it only makes sense to use setForceWriteLock(true) on read. Normally when you do an cache.get(fqn) an read lock is aquired, but setting the forceWriteLock to true would force a write lock acquisition. when you do a put(fqn)(generally a write), a WL (write lock) is acquired so having the flag is redundant. As a general rule, the forceWriteLock only apply for one call, i.e. for one invocation. | tm.begin(); | | // force write lock even on read operations | | cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true); | | | | // read node | | Object value = cache.get(myFqn, "key"); | | | | Object value = cache.get(myFqn2, "key"); | | | | tm.commit(); | | In this example a WL is acquired for myFqn and a RL is acquired for myFqn2 | | anonymous wrote : In other words, once I set the "setForceWriteLock(true)", all future cache related operations in this thread will see this option set to "true". No. Only the next call, after that the flag is cleaned. As mentioned in the previous post, an invocation is an call to the cache. I did a quick test and you are absolutely right. Just like what you pointed out in your sample code, after each read or write, the over write option is reset. This clears the confusion I had. Thanks! The reason for this post was that I'm trying to find a reliable way to do a "select for update" kind of operation in the new MVCC locking, i.e., a read followed by a write and the write value depends on the read result. Could you please comment on this thread? http://www.jboss.org/index.html?module=bb&op=viewtopic&t=161530&a... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258508#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...