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.

Yeah, just another example of the differences between OTS and JTA. I'm not sure it makes a great deal of difference if you keep with the HM for JTS and UCE for local JTA for now - it's a more accurate implementation for sure and then we could see if enough people complain about the different behaviour later. Definitely needs to be documented.

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.

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 think the configuration option makes the code harder to maintain longer term. Why not just go with HM for local JTA and be done with it until/unless enough concerns are raised? Then only the local JTA code changes, right?

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.