[infinispan-issues] [JBoss JIRA] (ISPN-2081) Transaction leak caused by reordering between prepare and rollback

[Mircea Markus (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726257#comment-12726257 ] 

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.infinispan-dev+page:1+mid:xgnmtee56jpqifs6+state:results  

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