Hi,

I would like to check with you behaviour of JTS implementation when transaction is started at client side, the WildFly receives call, running as a subordinate transaction manager and crashes during the processing.

The scenario is:

1. client starts JTS transction and calls WildFly
2. WildFly starts the subordinate transaction and enlists two XA resources - first resource is read only and second covers sending a message to a JMS broker
3. during 2PC WildFly prepares both resources - the first is read only and thus it' ommitted from later commit, while the JMS resource is prepared
4. WildFly commit continue with JVM crash where JMS commit was launched
5. client gets error message on the remote call processing which consist a HeuristicHazard exception
6. transaction at the client side is passed to the perirodic recovery processing
7. periodic recovery retries to finish the remote transaction - aka calls commit. When the WildFly is restarted again the JMS resource is committed.

I expect the behaviour is fine from "data consistency" point of view. I wonder about the client expectations.

The client gets the error message with heuristic error. It can see heuristic, anything could happen. And then, after few minutes the transaction is committed, ultimately. Is good the recovery manager still tries to commit in such situation? Client expects crash but I think it does not expect in progress state which is finished after few (ten) minutes.

What do you think about this behaviour?

Thanks for any thoughts

Ondra