[infinispan-issues] [JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent
Mircea Markus (JIRA)
jira-events at lists.jboss.org
Thu Nov 7 07:18:02 EST 2013
[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mircea Markus updated ISPN-3556:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> When LockControlCommand fails on an owner, the rollback command is not sent
> ---------------------------------------------------------------------------
>
> Key: ISPN-3556
> URL: https://issues.jboss.org/browse/ISPN-3556
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners.
> However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners.
> This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after.
--
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