1 of 1 people found this helpful
1. cache.getAdvancedCache().lock(k) is an rager lock. This means that after the method returns the given key is locked across the cluster: the key might not reside on this node (depending on its hash code), so this method will do a RPC and make sure that no other tx is able to write it before this tx finishes (commit/rollback).
On the other hand, .withFlags(Flag.FORCE_WRITE_LOCK) forces the acquisition of an write lock even if the operation you are performing is a read. The lock is not being acquired eagerly, meaning that if the key is not on this node, the actual WL is acquired on the key's owner at commit time.
2. This is an interesting question. I've just added a UT to check it (AsyncWithTxTest on 4.1 branch) and the cache.putAsync(K,V5) does not run under TX scope. I think this behavior is correct but it should be clearly specified (if it is not already) - other opinions?
If eagerlocking is set to false, concluded from document about asynchronous API, I think a cluster wide lock will be acquired during the prepare phase. Will the replication complete before transaction comitted or after that?
yes, cluster wide locks is acquired at prepare phase. The replication is performed before transaction commited: locks being acquired at prepare phase and being commited at commit phase (2PC).
During the prepare phase, if other transaction is processing commiting and has a lock on the same key in other node, will the XAResource wait for the lock to be granted util timeout? or will it fails the transaction immediately?
it will wait for "lockAcquisitionTimeout" millis (this can be 0).
4) For my example, replace and put operation both works, which one is recommended for better performance.
They have different semantics, so not sure what you mean.