If an error condition is required to be raise, one option is to raise a specialised (i.e. none-spec) form of SystemException as we have in a number of other situations: narayana/UnexpectedConditionException.java at master · jbosstm/narayana · GitHub

If we were to go with this approach, would that cause any of our existing users an issue - please do respond if it would break your existing applications.

Was just working my way through this and I am not sure about what to do about a JTS commit_one_phase...

2.8.4 commit_one_phase If possible, the resource should commit all changes made as part of the transaction. If it cannot, it should raise the TRANSACTION_ROLLEDBACK standard exception. If a failure occurs during commit_one_phase, it must be retried when the failure is repaired. Since their can only be a single resource, the HeuristicHazard exception is used to report heuristic decisions related to that resource. If a heuristic exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit_one_phase is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction.

For OTS it looks like HeuristicHazard could be a suitable outcome if we want to go down the route of an exception in the case as it is says the decision *may* have been made: "A request raises the HeuristicHazard exception to report that a heuristic decision may have been made" but on the coordinator side we do transpose HeuristicHazard to HeuristicMixed already so that would mean for JTS mode we would end up with HeuristicMixed for this scenario with JTS and UnexpectedConditionException for local JTA.

I have been looking into this and to introduce the ability to throw an UnexpectedConditionException for local JTA is actually quite an invasive change. It would either mean revising how we handle FINISH_ERROR in BasicAction or the addition of a whole new TwoPhaseOutcome and maybe even ActionStatus.

What I propose therefore is to make the local JTA and JTS scenarios both raise a HM. I do agree this is not ideal so I propose to make the option configurable as can be seen over here: https://github.com/jbosstm/narayana/compare/master...tomjenkinson:RMFAIL1PC

It may get Christian over his hurdle for JBTM-1702 and the more invasive change could then be left until we had more community feedback.

I would propose:

1. Raise a Jira to get UCE for an RMFAIL from commit_one_phase

2. Raise another Jira to get HM for RMFAIL from commit_one_phase as a workaround (and link to Jira in step 1)

3. Resolve jira from step 2 with my commit (linked above)

4. Wait for more community votes to get the more accurate UCE for local JTA mode - this would likely not be achievable for JTS so that would need to remain with the less accurate HM for the foreseeable future anyway

I have updated Updated so that when a commit_one_phase gets an RMFAIL back we can throw by tomjenkinson · Pull Request #875 · jbosstm/n… so that there is no configuration option. Both the local JTA and JTAX implementations have been changed to return HeuristicHazard/HEURISTIC_HAZARD during XAResourceRecord commit_one_phase (or equivalent).

The PR has passed so it looks like it should be fine technically to introduce this - I won't create the Jira till tomorrow to give more opportunity for others to shout up if it will cause them an issue and assuming no further updates I will get this finished off tomorrow.

I have raised [JBTM-2443] Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL - JBoss Issue Tracker and am dealing with it. Hopefully it will pass and I will release Narayana 5.2.0 tomorrow (I categorised this as a feature request as it modifies existing behaviour).