XAExceptions thrown by Derby can have errorCode 0

• Key: DERBY-4141
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Kathey Marsden
• Reporter: Kathey Marsden
• Component/s: SQL
• Affects Version/s: 10.1.3.1, 10.2.1.6, 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.0.0
• Fix Version/s: 10.3.3.1, 10.4.2.1, 10.5.1.1, 10.6.0.0

Description

When an XAException occurs during xa.start() or other XA operation, because of an SQLException, we have an errorCode of 0, regardless of the severity. I would suggest XAER_RMFAIL for SESSION_SEVERITY or greater and XAER_RMERR for lower severity exceptions. See thread http://www.nabble.com/XAException.errorCode-on-XAException-caused-by-an-SQLException-tt22832423.html for more detail and a reproduction.

Comments

[Kathey Marsden]

Well these changes look pretty straight forward for embedded. See attached preliminary patch (derby-4141_embedded_diff1.txt), but looking at the client code in NetXAResource it seems for any SQLException we use errorCode XAER_RMERR. I am not sure how to determine if it is a session ending exception on client. Does anyone know how to do this?

Also, I need a better test to provoke an SQLException within an XA operation. My current test case, which shuts down the database causes an assertion on the server and a NPE on the client when run with network server. Any ideas on a better test case would be welcome. I don't really see the assertion and the NPE as bugs as Derby can't really be so defensive as to gracefully handle someone shutting the database down from underneath.

The patch is not tested and is not ready for commit, but adapts the client model of setting both the message and the errorCode for all XAExceptions. If not one of the SQLStates with a straightforward mapping, it will set the errrorCode to XAER_RMFAIL for SESSION_SEVERITY or greater and XAER_RMERR for less severe errors. With the old code for embedded we would set either the message or the errorCode, but not both.

[Kathey Marsden]

I see am.SqlCode has the disconnect exception at 40000, so I could use XAER_RMFAIL for those but I think that severe exceptions from the server don't get that code.

[Kathey Marsden]

Just closing the XAConnection gives me a good enough reproduction for the XAER_RMFAIL case and in that case the XAER_RMFAIL errrorCode seems to get transfered properly to client.

[Kathey Marsden]

The attached patch (derby-4141_diff.txt) has the client and embedded changes and adds a test for the XAER_RMFAIL case. I couldn't figure out a case for testing the XAER_RMERR case, (non-session ending exception that causes an xa operation to fail), but if anyone has any ideas, please let me know and I'll add a test for that too.

For client I mapped the disconnect exception to XAException.XAER_RMFAIL and verified that server side exceptions that cause XAExceptions do indeed get the errorCode from the server. I think this resolves my concerns about client side SQLExcetptions.

Running tests now. I would like to backport this change to 10.3. It is a behavior change, but I think a sensible one that is low risk. Please let me know if you have any concerns.

[Kathey Marsden]

Tests passed. please review.

[Kathey Marsden]

Myrna asked me to pre-close this issue so it makes the 10.5.1.1 release notes. I actually plan to check into 10.5 tomorrow morning after checking the nightly runs.