Thanks for the reply.

So if I need to read a node, then write to it, such as:

 tm.begin();
 // force write lock even on read operations
 cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);

 // read node
 Object value = cache.get(myFqn, "key");

 // write node
 cache.put(myFqn, "key", "newValue");

 tm.commit();

Thanks for the reply!

Your explanation makes sense, however, it seems conflict with sample in the http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.2.0.GA/userguide_en/html_single/index.html#configuration.options.


Will that be true that if the override is inside a transaction, the lock will be kept for the rest of the transaction?

"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

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.