-
Bug
-
Resolution: Done
-
Critical
-
7.4.8.CR2
-
False
-
None
-
False
-
-
-
-
-
-
+
-
-
-
Similar behaviour is already described in https://issues.redhat.com/browse/JBEAP-9730
Consider this scenario:
1) We have CMR datasource configured
2) We use this datasource to create a transaction
3) The connection to DB is unavailable for a brief moment (Simulated by injecting throw of SQLException to first call of java.sql.Connection.commit() )
4) I expect that the transaction should be rollbacked and the state of DB should stay unchanged
The step 4 seems not to happen. I can see that a rollback exception was thrown in server log, but the transaction is committed anyway.
The committed transaction seems to be caused by resetting the autoCommit property of connection in Ironjacamar, see: https://github.com/ironjacamar/ironjacamar/blob/main/adapters/src/main/java/org/jboss/jca/adapters/jdbc/BaseWrapperManagedConnection.java#L365
This behaviour seems to be same for all tested database drivers except MsSQL. I believe that this is due of MsSQL driver's implementation of endRequest method. See https://github.com/microsoft/mssql-jdbc/blob/d842883e3e69420a7a798294cb58ac252eead011/src/main/java/com/microsoft/sqlserver/jdbc/SQLServerConnection.java#L7197
This method resets the autoCommit property by itself and also rollbacks the connection if transaction was started. The reset of autoCommit by driver is also interesting in context of autoCommitOnCleanup property of Ironjacamar. For more info see: https://issues.redhat.com/browse/JBJCA-1431
It can be reproduced using a little bit adjusted CMT quickstart
- is incorporated by
-
JBEAP-24667 (7.4.z) Upgrade Ironjacamar from 1.5.11.Final-redhat-00001 to 1.5.15.Final-redhat-00001
- Closed
- is related to
-
JBEAP-24500 Possible data inconsistency when CMR fails at Commit phase
- Closed
- relates to
-
JBJCA-1467 Don't reset autoCommit on destroyed connections
- Resolved
-
JBEAP-9730 Incorrect outcome when CMR fails at commit phase
- Reopened