Uploaded image for project: 'IronJacamar'
  1. IronJacamar
  2. JBJCA-1431

Reset autocommit during cleanup


    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 3.0.0
    • None
    • None
    • None

      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)

            tadamski@redhat.com Tomasz Adamski
            tadamski@redhat.com Tomasz Adamski
            0 Vote for this issue
            4 Start watching this issue