[
https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-5623:
------------------------------------
We should probably waiting for backup/pending locks based on the current topology id, not
the transaction's topology id. It might be necessary to clean the list of backup
locks, in order to avoid 2 txs both acquiring only backup locks and waiting for each other
on retry.
Retried prepare commands do not wait for backup locks
-----------------------------------------------------
Key: ISPN-5623
URL:
https://issues.jboss.org/browse/ISPN-5623
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 7.2.3.Final, 8.0.0.Beta1
Reporter: Dan Berindei
Fix For: 8.0.0.Beta2
Attachments: OptimisticPrimaryOwnerCrashDuringPrepareTest.java
When the primary owner crashes during prepare, the prepare command is retried on the new
primary owner. But because the transaction topology id stays the same, the new primary
owner does not check for backup locks owned by other transactions from the previous
topology.
That makes it possible for the retried prepare command to lock a key that was already
locked by another transaction on the primary owner.
This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would
have forced the transaction to roll back.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)