[infinispan-issues] [JBoss JIRA] (ISPN-1483) Stale locks with eager/pessimistic locking after the prepare command fails on a remote node

[Dan Berindei (Updated) (JIRA)]

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

Dan Berindei updated ISPN-1483:
-------------------------------

        Fix Version/s: 5.1.0.BETA3
    Affects Version/s: 5.1.0.BETA2
                       5.0.1.FINAL
          Component/s: Locking and Concurrency

    
> Stale locks with eager/pessimistic locking after the prepare command fails on a remote node
> -------------------------------------------------------------------------------------------
>
>                 Key: ISPN-1483
>                 URL: https://issues.jboss.org/browse/ISPN-1483
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency
>    Affects Versions: 5.0.1.FINAL, 5.1.0.BETA2
>            Reporter: Dan Berindei
>            Assignee: Dan Berindei
>             Fix For: 5.1.0.BETA3
>
>
> When a PrepareCommand fails (in our case because it didn't get a reply from the remote node in 15 seconds), the locking interceptor catches the exception and releases all the locks acquired by the transaction.
> After that TransactionCoordinator starts a proper rollback, but the entries in the invocation context are no longer locked (and in 5.0 that means they only have the VALID flag set, not CHANGED or CREATED). That means local locks are not released twice, but it also means the PrepareCommand is not executed remotely (BaseRpcInterceptor.shouldInvokeRemoteTxCommand() returns false).
> In 5.1 we no longer have the entry flags but the entries are still locked.
> I see 3 possible solutions:
> 1. Don't clean up the locks at all in LockingInterceptor (if the invocation context is transactional) and rely on TransactionCoordinator to do it.
> 2. Clean up the locks but don't call rollback() on the entry.
> 3. Rely on LocalTransaction's getRemoteLocksAcquired() instead of the locked entries to determine if the rollback command should be executed on the remote nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira