[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
Wed Oct 9 13:22:02 EDT 2013


     [ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mircea Markus updated ISPN-3556:
--------------------------------

    Fix Version/s:     (was: 6.0.0.Final)

    
> 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: Dan Berindei
>            Priority: Critical
>
> 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