Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-7786

Support system property to disable validation of JDBC JCA recovery connection

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: EAP_EWP 5.1.2
    • Fix Version/s: EAP_EWP 5.2.0
    • Component/s: JCA
    • Labels:
      None
    • Affects:
      Documentation (Ref Guide, User Guide, etc.), Release Notes
    • Workaround:
      Workaround Exists
    • Workaround Description:
      Hide

      Possible work-arounds:

      1) Stop the JDBC datasource's ManagedConnectionFactory MBean. That will terminate the recovery connection and allow DB2 to be restarted.
      2) Use <no-recover>true</no-recover> on the JDBC datasource to disable recovery altogether. This is not recommended long-term as recovery is an important part of transaction integrity.

      Show
      Possible work-arounds: 1) Stop the JDBC datasource's ManagedConnectionFactory MBean. That will terminate the recovery connection and allow DB2 to be restarted. 2) Use <no-recover>true</no-recover> on the JDBC datasource to disable recovery altogether. This is not recommended long-term as recovery is an important part of transaction integrity.
    • Release Notes Text:
      Hide
      The JBossTS transaction recovery manager was previously improved to prevent a stale JDBC connection for XA recovery by checking the validity of the connection before making any calls to the driver. In the case of the DB2 JDBC driver however, the validity check caused a connection to the database to be opened and remain open, preventing a planned shutdown of the DB2 RDBMS instance even though no activity was in progress. To prevent this occurring, a new system property - recover-connection-validation - has been created, allowing validation to be turned off, for example: <parameter>-Drecover-connection-validation=</parameter><literal>false</literal>.
      Show
      The JBossTS transaction recovery manager was previously improved to prevent a stale JDBC connection for XA recovery by checking the validity of the connection before making any calls to the driver. In the case of the DB2 JDBC driver however, the validity check caused a connection to the database to be opened and remain open, preventing a planned shutdown of the DB2 RDBMS instance even though no activity was in progress. To prevent this occurring, a new system property - recover-connection-validation - has been created, allowing validation to be turned off, for example: <parameter>-Drecover-connection-validation=</parameter><literal>false</literal>.
    • Release Notes Docs Status:
      Documented as Resolved Issue
    • Docs QE Status:
      NEW

      Description

      JBPAPP-5292 resolved the issue where the JBossTS transaction recovery manager would receive a stale JDBC connection for XA recovery by calling java.sql.Connection.isValid(int) to ensure the connection was valid. However, in DB2 a call to java.sql.Connection.isValid(int) causes the connection made from the DB2 JDBC driver to the back-end DB2 RDBMS to become "active" which prevents an administrative shutdown of the DB2 RDBMS instance. To deal with this quirk in the DB2 implementation of java.sql.Connection.isValid(int) we should support a new system property named "recover-connection-validation" which can be used to turn the validation off, e.g.:

      -Drecover-connection-validation=false

      Using "false" for "recover-connection-validation" will force the recovery connection used for an XA JDBC datasource to be re-created every time the JBossTS transaction recovery manager asks for it.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  jbertram Justin Bertram
                  Reporter:
                  jbertram Justin Bertram
                  Writer:
                  Russell Dickenson
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: