]
Mircea Markus updated ISPN-2995:
--------------------------------
Fix Version/s: 5.3.0.Final
(was: 5.3.0.CR1)
FineGrainedAtomicHashMap may not lock all the composite keys in
optimistic locking
----------------------------------------------------------------------------------
Key: ISPN-2995
URL:
https://issues.jboss.org/browse/ISPN-2995
Project: Infinispan
Issue Type: Bug
Components: Fine-grained API
Affects Versions: 5.3.0.Alpha1
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Labels: atomic_map, locking
Fix For: 5.3.0.Final
In OptimisticLockingInterceptor, we are collecting the composite keys from
ApplyDeltaCommand is the key belongs to the node:
{code}
case ApplyDeltaCommand.COMMAND_ID:
ApplyDeltaCommand command = (ApplyDeltaCommand) wc;
if (cdl.localNodeIsOwner(command.getKey())) {
Object[] compositeKeys = command.getCompositeKeys();
set.addAll(Arrays.asList(compositeKeys));
}
break;
{code}
However, when we are going to acquire the lock in the node if it is the primary owner:
{code}
protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long
lockTimeout, boolean skipLocking) throws InterruptedException {
if (cdl.localNodeIsPrimaryOwner(key)) {
lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking);
} else if (cdl.localNodeIsOwner(key)) {
ctx.getCacheTransaction().addBackupLockForKey(key);
}
}
{code}
The CompositeKey should always acquire the lock.
This is probably a bug. Add an unit test to verify that locking works as expected for
AtomicHashMap.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: