[infinispan-issues] [JBoss JIRA] (ISPN-2995) AtomicHashMap locking issue [optimistic]
Dan Berindei (JIRA)
jira-events at lists.jboss.org
Tue May 14 04:20:06 EDT 2013
[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773993#comment-12773993 ]
Dan Berindei commented on ISPN-2995:
------------------------------------
This is odd, I would have thought AtomicHashMap would only acquire a lock on the parent key and only FineGrainedAtomicHashMap would acquire locks on all the composite keys. Are you sure ApplyDeltaCommand is used for AtomicHashMap?
For FGAHM, it would be nice to use grouping to keep the composite keys on the same node as the parent key (but then we'd have to enable grouping all the time, and I'm not sure if that's an option).
> AtomicHashMap locking issue [optimistic]
> ----------------------------------------
>
> 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.Beta2
>
>
> 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: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list