[
https://issues.jboss.org/browse/ISPN-2081?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-2081:
-------------------------------------
[~dan.berindei]"Say the local node (B) is a backup owner for key k1, the tx (tx1)
acquires the lock locally" <-- in this situation the transaction would not acquire
any lock locally, but just set the value of backup lock flag. The lock acquisition when
run locally is no different from when run remotely.
The situation I've described happens when the main owner of k1 is B and the the local
tx cannot acquire a lock on it. In this case, with the current code, a remote rollback is
sent even though the tx hasn't left the originator node. This is sub-optimal for now,
but as we plan to create a remote transaction during rollback as well, this is not allowed
to happen as that tx would leak.
Transaction leak caused by reordering between prepare and rollback
------------------------------------------------------------------
Key: ISPN-2081
URL:
https://issues.jboss.org/browse/ISPN-2081
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.1.5.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Priority: Blocker
Labels: jdg, jdg6
Fix For: 5.2.0.CR1, 5.2.0.Final
Attachments: DistL1WriteSkewTest.txt, RollbackNotSentBeforePrepareTest.java
There's no ordering between the prepare and commit/rollback messages, as the later
are sent OOB.
With this in mind, the following transaction leak might happen:
Tx1 send prepare on nodes {A,B}
1. the message reaches A and timeouts but hasn't yet been processed on B
2. The transaction originator reacts immediately to the timeout received from A without
waiting the response from B and sends a rollback request
3. The rollback request is processed on A and B
4. The initial prepare is then processed on B
At this point we have an orphan transaction prepare on B.
Whilst this is not causing any inconsistencies, it keeps keys locked indefinitely and is
a memory leak.
The solution would be to wait at 2 for all the prepare messages *before* sending the
rollback.
Attached is a unit test to reproduce the issue.
Related mailing list thread:
http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in...
--
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