Created attachment 879117 [details] server.log It seems that there is some troubles in finishing transaction on CMR connection when RuntimeException is thrown during CMR commit. In such case the second access to the connection causes XAException.XAER_PROTO being thrown. The log contains error like this: WARN [com.arjuna.ats.jta] (EJB default - 8) ARJUNA016061: TransactionImple.enlistResource - XAResource.start returned: XAException.XAER_PROTO for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-863b1bb:5332e12f:4a, node_name=1, branch_uid=0:ffff7f000001:-863b1bb:5332e12f:4e, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >: org.jboss.jca.core.spi.transaction.local.LocalXAException: IJ001151: Trying to start a new transaction when old is not complete: Old: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-863b1bb:5332e12f:3c, node_name=1, branch_uid=0:ffff7f000001:-863b1bb:5332e12f:41, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >, New < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-863b1bb:5332e12f:4a, node_name=1, branch_uid=0:ffff7f000001:-863b1bb:5332e12f:4e, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >, Flags 0 The test flow is following: 1) prepare jdbc cmr resource 2) prepare test xa resource 3) commit jdbc cmr resource - RuntimeException is thrown 4) commit test xa resource 5) checking values in the database table - for this check is used CMR datasource - at this point the start of the transaction fails with the exception mentioned above
Created attachment 879118 [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=JPAInjectedFailureCMRTestCase#injectRuntimeExceptionOnCommit -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
This is connected with upstream jira: https://issues.jboss.org/browse/JBTM-2132 In current state there is not needed to throw RuntimeException (which is maybe incorrect test scenario) but when LocalXAException (excepted exception which RM could throw) is thrown then the result with not finished transaction on connection is the same. Which means that the second call using the same connection is failing because of not finished txn.
Created attachment 882377 [details] ds.properties file for oracle
Reading comment #9, I am setting this to MODIFIED in line with the component upgrade
I've done checks with Narayana 4.17.19.Final (expected to be in ER2) and I agree with Mike that this is probably not an issue which could be found in real application. What I think is: The only possible "real" exception seems to be the ResourceException when commit fails on javax.resource.spi.LocalTransaction. The JCA layer expects that local transaction is not part of the any global one. The catch block catches the the fail of resource and returns connection to pool. When the catch block is not reached then the second usage of the connection causes the exception being thrown. So there could be any exception being thrown - runtime or not runtime in any part of the LocalXAResourceImpl class and it would cause that the connection won't be usable next time. But as I tried to explain - my point of view is that it seems that this will not happen. The code of the LocalXAResourceImpl is here: https://github.com/ironjacamar/ironjacamar/blob/e45ca1459f4b960e81ab6cfa6322cb4464a5cf68/core/src/main/java/org/jboss/jca/core/tx/jbossts/LocalXAResourceImpl.java#L163 When I will get the EAP 6.3.0.ER2 I will check the change of the narayana version and run our tests against it. If there is no other issue found then this issue is fixed from my point of view.
As mentioned in comment above I consider this as fixed issue. Verified for EAP 6.3.0.ER2.
Micheal, does this issue require a release note in the 6.3.0 Beta documentation? Ondrej's comment 11 suggests this wasn't an issue that would impact a customer. If this does need to be documented in the release notes, could you please provide a draft note in the Doc Text field above?
Marking as not requiring a release note as per doc lead instruction. If this is incorrect, please supply a draft release note in the Doc Text field and set the requires_doc_text flag to '?' Cancelling NEEDINFO request.