Please consider a scenario with hosts with "EmbeddedCaches" configured as a cluster (clustering mode: replicated, isolation level: READ_COMMITTED, synchroneous replication).
Host 1 Host 2
Note: both keys existed in the cache before the transactions started.
Lock on K1 is successfully acquired by host1 at step 3.
At step 4, host2 fails to acquire lock on K2 until transaction on host1 is either committed or rollback or until the lock acquisition process times out.
--> This looks rather strange to me since I would expect that the second host could lock K2 without any problem since nobody in the cluster holds a lock on it at this time.
Can someone tell me what I missed ?
PS: this test was made with Infinispan 4.2.1.CR1, transactions controlled via the DummyJTATransaction manager.
Back on the subject - found (I guess) the solution
Issue is related to Lock Striping (cfr. http://community.jboss.org/wiki/LockingandConcurrency#Lock_striping)
According to the documentation, lock striping is enabled by default.
Lock striping entails the use of a fixed-size, shared collection of locks for the entire cache, with locks being allocated to entries based on the entry's key's hash code. This means two different keys may share the same lock - which is the case in my example.
I disabled lock striping and my test now runs fine (or at least as expected).
Conclusion: in you fine fine-graine lock, then either disable lock striping or carefully choose your hashcode generation for the keys...
|Retrieving data ...|