[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1049) transaction participant failure after prepare causes data inconsistency

[Mircea Markus (JIRA)]

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

Mircea Markus commented on ISPN-1049:
-------------------------------------

The problem stands for recovery as well - it's just with recovery, the user can re-conciliate state through JMX tooling.
Below is the solution I have in mind.

When commit message is received 
- check that all the nodes that prepared are still present in the cluster
- yes - proceed with commit and return control to TM  
- no - unicast the prepare to the new data owner(s) 
- If prepared successfully on new owner(s) the commit the transaction and return control to TM
- If couldn't prepare on the new owners:
     a) recovery is enabled - just throw an exception to TM and recovery process will handle it
     b) recovery not enabled - try to rollback the tx, and signal this as an exception(XA_HEURRB) to the TM 




> transaction participant failure after prepare causes data inconsistency 
> ------------------------------------------------------------------------
>
>                 Key: ISPN-1049
>                 URL: https://issues.jboss.org/browse/ISPN-1049
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 4.2.1.FINAL
>            Reporter: Mircea Markus
>            Assignee: Mircea Markus
>             Fix For: 5.0.0.FINAL
>
>         Attachments: ParticipantFailsAfterPrepareTest.java
>
>
> cluster {A, B, C, D}, dist, numOwners=3.
> transaction started on A touches B and C. A prepares then C crashes.
> When TM commits the user gets a TimeoutException as commit rpc to C failed.
> The state of the cluster after commit is: tx state successfully applied on A and B, but not on D!
> The tx should successfully be applied on D as well, as numOwners=3. Or, at least, it should rollback on A and B as well; the point being the cluster should remain in a consistent state.   

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira