1 Reply Latest reply on Dec 15, 2008 7:59 AM by Adrian Brock

    connection management on tx timeout

    Jonathan Halliday Master

      A couple of questions related to JBAS-5080, i.e. how connections behave if used either side of a asynchronous transaction timeout.

      Am I right that the expected behaviour of a connection handle obtained in a transaction but subsequently used after that transaction has been rolled back on another thread, is that it should behave as if closed? The JIRA is not too clear on what the actual fix was.

      Now the more difficult one: what's the expected JCA behaviour when a Thread that has a transaction context representing an aborted transaction, asks for a new connection? This happens if a transaction timeouts and is rolled back in the background, then the application logic tries to obtain a new connection. The new connection should be part of the ongoing global tx, but that tx is dead. Hopefully the getConnection call will throw an exception if the tx state is other than active?

      Thanks

        • 1. Re: connection management on tx timeout
          Adrian Brock Master

           

          "jhalliday" wrote:
          A couple of questions related to JBAS-5080, i.e. how connections behave if used either side of a asynchronous transaction timeout.

          Am I right that the expected behaviour of a connection handle obtained in a transaction but subsequently used after that transaction has been rolled back on another thread, is that it should behave as if closed? The JIRA is not too clear on what the actual fix was.


          It will throw a RollbackException (wrapped in an SQLException) if you try to use
          the connection or one of its child objects (e.g. a statement)
          after the transaction is aborted.


          Now the more difficult one: what's the expected JCA behaviour when a Thread that has a transaction context representing an aborted transaction, asks for a new connection? This happens if a transaction timeouts and is rolled back in the background, then the application logic tries to obtain a new connection. The new connection should be part of the ongoing global tx, but that tx is dead. Hopefully the getConnection call will throw an exception if the tx state is other than active?


          Correct. The pool does a check early to avoid unnecessary allocation of a connection,
          but the real definitive test is when it tries to do the Transaction.enlistResource()