[infinispan-issues] [JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache

[Eugene Scripnik (JIRA)]

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

Eugene Scripnik updated ISPN-6745:
----------------------------------
    Description: 
When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction before current transaction ends.

So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.

I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.

I am attaching Test which reproduces this problem

  was:
When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction.

So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.

I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.

I am attaching Test which reproduces this problem



> Locks are lost in pessimistic cache
> -----------------------------------
>
>                 Key: ISPN-6745
>                 URL: https://issues.jboss.org/browse/ISPN-6745
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 7.2.3.Final
>         Environment: JBoss DataGrid 6.5.0 (6.3.1.Final-redhat-1)
> 3 nodes in REPL_SYNC mode
> pessimistic locking
> read committed isolation
>            Reporter: Eugene Scripnik
>         Attachments: InfinispanNodeFailureTest.java
>
>
> When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction before current transaction ends.
> So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.
> I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.
> I am attaching Test which reproduces this problem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)