[infinispan-issues] [JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)

[Mircea Markus (JIRA)]

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

Mircea Markus updated ISPN-2588:
--------------------------------

    Fix Version/s: 5.2.0.Final
                       (was: 5.2.0.CR1)

    
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
>                 Key: ISPN-2588
>                 URL: https://issues.jboss.org/browse/ISPN-2588
>             Project: Infinispan
>          Issue Type: Bug
>          Components: State transfer
>    Affects Versions: 5.2.0.Beta5
>            Reporter: Mircea Markus
>            Assignee: Dan Berindei
>            Priority: Critical
>             Fix For: 5.2.0.Final
>
>         Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster) 
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which  invokes:
> {code:java} 
>    protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
>       return ctx.isOriginLocal() && (ctx.hasModifications()  ||
>                                            !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
>    }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.

--
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