This issue tracks the modification of ArjunaJTA/JTS to avoid invoking rollback when it is not needed. Moreover, once the modifications are implemented, it is also needed to remove JTAEnvironmentBean:xaRollbackOptimization as this config option will be no longer needed.

Why?

[From page 8 of the XA spec, section 2.3.1]

The TM does not issue Phase 2 requests to RMs that responded negatively in Phase 1. The TM does not need to record stably the decision to roll back nor the participants in a rolled back global transaction.

This tells us that ArjunaJTA should not send rollback to a resource manager that replied with XA_RBINTEGRITY (i.e. responded negatively to phase 1). In fact, ArjunaJTA treats all these error codes in the same way.
The current solution is based on the assumption that a RM should return XAER_NOTA when replying to a rollback request for an XID that doesn't exist. This makes our choice a legit solution (even though we're calling rollback on RMs that have already rolled back their branch). In fact, returning XAER_NOTA on a rollback request for an XID that doesn't exist would also cover situation where the transaction manager might not receive the XA_RBINTEGRITY from the RM, for example, in the case of a network issue. The current solution is a reflection of the assumption that, back in the days, not all RMs where XA compliant thus ArjunaJTA/JTS needed to invoke rollback on all RMs to make sure that the rollback took place. Nowadays, this assumption is no longer realistic as most (if not all) RMs are XA compliant.

As a consequence, the config option JTAEnvironmentBean:xaRollbackOptimization (which was introduced to avoid calling rollback for all XA error code) can be deprecated (especially considering that, at the moment, this optimization doesn't work as it should) and then removed in a future major release.