We found a problem with Aries managed XA transactions and Oracle JDBC.

In a nutshell, if the database raises an SQL exception within the scope of an XA exception (in our example XA transacted Camel route), the JDBC connection cleanup routine of org.tranql tries to enable auto commit on the Oracle JDBC connection, which raises an SQL exception and causes the connection to be closed.
As a result the tx rollback that happens thereafter (due to original SQL exception) fails as the underlying JDBC connection is already closed.

I managed to find the culprit in method org.tranql.connector.jdbc.ManagedXAConnection.cleanup():

// org.tranql.connector.jdbc.ManagedXAConnection.cleanup()
public void cleanup() throws ResourceException {
       super.cleanup();
       Connection c = physicalConnection;
       try {
           //TODO reset tx isolation level
           if (!c.getAutoCommit()) {
               c.setAutoCommit(true);       <—————— 
           }
       } catch (SQLException e) {
           throw new ResourceException("Could not reset autocommit when returning to pool", e);
       }
   }

Calling c.setAutoCommit(true) on the Oracle JDBC connection raises:

"java.sql.SQLException: could not turn on auto-commit in an active global transaction"

Everything else is a follow up of this problem. The JDBC connection gets closed and later attempts to rollback the tx raises

"java.sql.SQLRecoverableException: Closed Connection”

Even though Aries retries the rollback, it never succeeds as it seems to hold on to the same JDBC connection that remains closed.
So the rollback functionality does not work properly when using Oracle ojdbc6 drivers [1].

It seems the call to c.setAutoCommit(true) is wrong at this stage. The error thrown seems reasonable

"java.sql.SQLException: could not turn on auto-commit in an active global transaction"

I can happily share a test case.