Thanks for the query! I think I would need some more detail to understand a circumstance where they throw a different exception and to try to work out whether it would have a negative effect on Narayana but in principal the spec defines this quite clearly for rollback/commit/prepare:
The specified XID is not known by the resource manager
Here is where we process (at least JTA, if not JTS) - you can see what we would do with the invalid conditions and whether we would treat them similarly.
Good luck with the research!
Good to know for me that throwing XAER_NOTA is expected behavior. To get closer to particular cases when DBs behaves differently I started with PosgreSQL. There is nicely to see that they take care of rollback
but not for commit and prepare
From experience with testing Narayana I can say that calling rollback with non-existent Xid is often. What I remember recovery manager makes such calls. But at time of recovery there is no running transaction so throwing different exception does not influence txn consistency - at the most some warning is shown in log.
Checking the jdbc drivers for dbs which we work with the matrix of behavior is following
PosgreSQL PosgresPlus Oracle DB2 MySQL MariaDB Sybase MSSQL commit XAER_RMERR XAER_RMERR XAER_NOTA XAER_NOTA XAER_NOTA XAER_NOTA XAER_NOTA XAER_NOTA rollback XAER_NOTA XAER_NOTA No exception XAER_NOTA XAER_NOTA XAER_NOTA XAER_NOTA XAER_NOTA prepare XAER_RMERR XAER_RMERR XAER_NOTA XAER_NOTA
Wrong behavior then contains
- XAER_RMERR on commit
- XAER_RMERR on prepare
- XAER_RMFAIL on prepare
- no exception on rollback
At Narayana side
- XAER_RMERR and XAER_RMFAIL on prepare behaves the same way as XAER_NOTA
- XAER_RMERR on commit causes TwoPhaseOutcome.HEURISTIC_ROLLBACK instead of TwoPhaseOutcome.HEURISTIC_HAZARD/nothing (caused by XAER_NOTA)
- here I'm not sure that this could have some serious impact on txn processing (?) but it does not seem to me so
- no exception on rollback seems being fine as well as handling of XAER_NOTA just returns TwoPhaseOutcome.FINISH_OK which is the same output
When I passed through these handling it seems to me that behavior of some jdbc drivers are not correct by spec but should not cause some trouble for data.
A side note:
My test for this is simple and working directly with XAResource, just to check if it comply with the spec in this particular way (call operation with uknown Xid), as it's reproducer for WFLY-7196.If there would be simulated some real case when DB forgets
Thank you for help
Thanks for the research Ondra. I agree with your analysis that even if non-compliant the invalid responses should not have an overall effect on the TX except to raise the HEUR rather than Hazard. The reason it is a HEURB is because the resource is categorically stating the branch was rolled back (which as it never existed is kind of similar in material effect).
I think you should raise issues on the drivers so they are aware of their compliance issues, you could quote the XA specification areas when raising the issues.
I started issues in the following way
Oracle: https://community.oracle.com/message/14108459#14108459 (decided to ask on forum first as creating a bug report is somehow quite a complicated)
Great - thanks Ondra