[
https://issues.jboss.org/browse/ISPN-1049?page=com.atlassian.jira.plugin....
]
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