4 Replies Latest reply on Mar 31, 2005 11:49 AM by Adrian Brock

    long-lived sessions and connection management

    Bill Burke Master

      Recent discussion between Adrian an I.

      On Wed, 2005-03-30 at 22:58, Bill Burke wrote:

      >> You said there are weird behaviors when a connection is kept open after
      >> TX. What if the connection is closed in afterCompletion? Is there
      >> gonna be a lot of overhead?


      There are two main problems (which I mentioned in earlier e-mails):

      1) The ordering of the synchronizations, i.e. does your
      connection.close() get invoked before the CCM's synchronization
      to check whether the connection is closed. Otherwise they will
      be invoked in the wrong order and the CCM will complain you
      didn't close the connection.

      2) The connections being allocated against in seemingly random EJB
      contexts as the CCM sees it. i.e. opened in one and closed in another

      (2) is the subject of that bug report I mentioned and started a
      discussion in the linked dev forum post.


      >>
      >> I ask this because I'm doing some special EJB3/Hibernate integration.

        • 1. Re: long-lived sessions and connection management
          Bill Burke Master

           

          "bill.burke@jboss.com" wrote:


          There are two main problems (which I mentioned in earlier e-mails):

          1) The ordering of the synchronizations, i.e. does your
          connection.close() get invoked before the CCM's synchronization
          to check whether the connection is closed. Otherwise they will
          be invoked in the wrong order and the CCM will complain you
          didn't close the connection.


          So, if the synchronization that closes the connection is registered before the CCM's synchronization, we're ok?

          If it is OK, I'll still get that stupid warning correct? Is there a way to turn off the CCM? I saw the Debug=true flag in the doco, but don't there doesn't seem to be a switch for it without specifying the entire MBean configuration for the connection pool.

          BTW, in EJB3 I currently do not have a CCM interceptor. Will this cause a leak within the connection pool's internal house-keeping?

          Thanks



          • 2. Re: long-lived sessions and connection management
            Adrian Brock Master

             

            "bill.burke@jboss.com" wrote:

            So, if the synchronization that closes the connection is registered before the CCM's synchronization, we're ok?


            No, because JCA registers one synchronization on first use of JCA in the transaction and accumulates other work in that (just like the entity bean global synchronization).
            See TxSynchronizer.


            If it is OK, I'll still get that stupid warning correct? Is there a way to turn off the CCM? I saw the Debug=true flag in the doco, but don't there doesn't seem to be a switch for it without specifying the entire MBean configuration for the connection pool.


            Don't understand this. The CCM is deployed once in jbossjca-service.xml


            BTW, in EJB3 I currently do not have a CCM interceptor. Will this cause a leak within the connection pool's internal house-keeping?

            If there is no context established on the thread by the interceptor, the CCM
            won't do the checking. You should still be able to see the unclosed connections
            on the CCM (list in use operation). But without the interceptor it is unreliable
            since it relies on the GC removing the closed connections from the WeakHashMap
            as they are closed/dereferenced.
            Unclosed connection handles will still be referenced (by the ManagedConnection)
            and so won't get GCed.


            • 4. Re: long-lived sessions and connection management
              Adrian Brock Master

               

              "adrian@jboss.org" wrote:
              JCA registers one synchronization on first use of JCA in the transaction and accumulates other work in that (just like the entity bean global synchronization).
              See TxSynchronizer.


              And to clarify this statement, JCA needs a tx synchronization in the following
              circumstances:

              1) track-connection-by-tx (true for all local datasources and at least OracleXA)
              to return the connection to the pool at the end of the transaction.
              2) If the EJB does not close the connection during the invocation, it registers
              a synchronization to check whether it was done later at transaction end.