Created attachment 878461 [details] server.log It seems that recovery with CMR as part of the transaction could cause data inconsistency. The test looks: 1) enlist test xa resource 2) enlist cmr db resource 3) prepare test xa resource 4) prepare cmr db resource 5) commit cmr db resource 6) crash app server 7) start server with recovery being stopped (byteman waiting on signal) 8) stop proxy 9) do recovery of test xa resource The test XA resource is rollbacked instead of being commited as CMR resource already was.
Created attachment 878462 [details] ds.properties file for oracle This could be reproduced by test case of crash recovery testsuite git clone -b lrco git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git cd eap-tests-transactions/jbossts export JBOSS_HOME=path/to/jboss-eap mvn clean verify -Dtest=JPAProxyCMRCrashRecoveryTestCase#commitHaltRecoveryProxyHalted -Dno.cleanup.at.teardown -Djbossts.noJTS -Dds.properties=path/to/ds.properties Jboss eap 6.3.0.DR5 could be downloaded from: http://download.devel.redhat.com/devel/candidates/JBEAP/JBEAP-6.3.0.DR5/jboss-eap-6.3.0.DR5.zip
I've just found that the order of operations is slightly different. The difference is in order of prepare calls. CMR resource is the first resource which is prepared. The correct order looks this: 1) enlist test xa resource 2) enlist cmr db resource 3) prepare cmr db resource 4) prepare test xa resource 5) commit cmr db resource ... (then see #c0)
Just for better explanation: The proxy is simple socket proxy java program which serves just to transfer data from input to output and gives us possibility to kill the connection - simulate connection failures. The term stop proxy means that connection to database is going to be down.
This is a bug in the implementation. The CMR recovery module should move the record into a different part of the recovery store so that it is ignored by the other recovery modules. If the connection to the database fails then the datasource does not get added to the collection queriedResourceManagers so in "Stage 2" of the algorithm the record does not get moved. The result of this bug is that one of the next recovery modules tries to recovery the transaction instead of the CMR recovery module which is the only one that knows how to determine what the CMR resource did. The fix is to move the line where we update the queriedResourceManagers list into the finally block so the datasource gets added even if the connection fails.
The problem was that our code for detecting "orphaned" transactions was processing the transaction log and ignoring the "commit marker" on the embedded record. The linked external bug tracker (JBTM-2132) fixes that oversight.
Tom Jenkinson <tom.jenkinson> updated the status of jira JBTM-2132 to Closed
Verified for EAP 6.3.0.ER2.
I've added a draft release note based on the information found in this ticket. Michael, can you please review the draft and amend as required? I found parsing the data challenging.
(In reply to Scott Mumford from comment #8) > I've added a draft release note based on the information found in this > ticket. > Michael, can you please review the draft and amend as required? I found > parsing the data challenging. Hi Scott I am assuming this is historical and you no longer need a response.