2 Replies Latest reply on May 14, 2008 9:05 PM by jeffzhang

    JBAS-3632

    jeffzhang

      I am looking this JIRA.

      (In CachedConnectionManager)
      If CloseConnectionSynchronization had been registered into TransactionSynchronizer, TM timout and afterCompletion method should be callback and close the current connections.

      This is JIRA case, am I right?

      But in runtime debug time, breakpoint in CloseConnectionSynchronization:afterCompletion() can not execute.
      Only in closeAll(), CloseConnectionSynchronization have change to register itself.

      Iit is hard to reproduce for this testcase, could someone give me some suggestion? Thanks

       CloseConnectionSynchronization cas = (CloseConnectionSynchronization) TransactionSynchronizer.getCCMSynchronization(tx);
       if (cas == null && createIfNotFound && TxUtils.isActive(tx))
       {
       cas = new CloseConnectionSynchronization();
       TransactionSynchronizer.registerCCMSynchronization(tx, cas);
       }
      


        • 1. Re: JBAS-3632

          I don't understand your question/comment.

          If it is "how do I reproduce it?" then you need to set up some ejb calls that does
          something like the following.

          1) Start a transaction, e.g. invoke a CMT/Required ejb method
          2) Make an ejb invocation on a different bean that opens a connection handle
          but doesn't close it (e.g. like the thread local connection tests in the testsuite)
          3) Force the transaction to timeout

          Previously we would wait until the transaction ends when the method in step (1)
          returns before checking for unclosed connections. This allows something
          to close the connection that was "cached".

          But since jboss-4.2.x the transaction timeout does the rollback which can
          will give a spurious warning in this case.

          NOTE: This usage is an anti-pattern and doesn't cause any real problems
          which is why I'm not really too worried about this issue.

          How it gets fixed is a different issue. It's tied up with the other JIRA issue
          about the CachedConnectionManager rewrite that is required such
          that it better understands the ejb lifecycle(s) and the "Debug" feature
          needs redoing so it isn't so contentious on the WeakHashMap.

          Search for other forum threads and links from the JIRA issues
          for more information and ideas.

          • 2. Re: JBAS-3632
            jeffzhang

            Thanks Adrian, I will do more investigate.