autoCommit algorithm optimization has different considerations in different databases. The issues that it impacts are as follows:
1 EAPSUP-872: setting autoCommit during cleanup results in performance penalty in some environments
2 JBAS-5678: modification of underlyingAutoCommit value reverts the fix of this issue
3 EAPSUP-591/JBJCA-1448: Stephen Fikes had doubts regarding the behavior of auto-commit; during the discussion IMO most things were clarified but one problematic case was left https://gitlab.cee.redhat.com/sfikes-test/share/-/tree/testing-with-h2-unexpected-committed-row . This is a case of BMT transaction with CachedConnectionManager's lazy enlistment. I have verified this scenario again and I'm not able to reproduce the problem. It would be good if someone double-check that because Stephen was saying in the conversation that he is able to see incorrect transactional behavior there.
4 PostgresSQL transactions in uncommitted stated after returning to pool as reported in: https://github.com/ironjacamar/ironjacamar/issues/734

To deal with all of this:

• ironjacamar.jdbc.setautocommitoncleanup system property is introduced; it decides whether autoCommit should be reset during cleanup
• by default autoCommit is reset during cleanup (ironjacamar.jdbc.setautocommitoncleanup set to true)
• during cleanup it is established if connection should be rollbacked during destroy, hence JBAS-5678 fix is preserved
• if performance penalty is too big, autoCommit on cleanup can be turned off, but the customer must be aware of implications (point 4 above)