[JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6745?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-6745:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1374428|https://bugzilla.redhat.com/show_bug.cgi?id=1374428] from ON_QA to VERIFIED
> 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
> Assignee: Pedro Ruivo
> Fix For: 8.2.4.Final, 9.0.0.Beta1
>
> 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
(v7.2.3#72005)
8 years, 6 months
- 1
- 0