Uploaded image for project: 'Application Server 3  4  5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-4667

Wrong logic in CachedConnectionManager.getCloseConnectionSynchronization()

    XMLWordPrintable

    Details

      Description

      If the tx is not active (for example it has STATUS_PREPARING), then the method always returns null, even if the associated CloseConnectionSynchronization exists.
      This results in wrong warnings about non-closed connections, since when the close() is called for a connector, in CachedConnectionManager.unregisterConnection() a null value is returned from getCloseConnectionSynchronization() and the connector remains in the list of non-closed resources for the transaction.
      I think this bug was introduced here: http://jira.jboss.com/jira/browse/JBAS-31#action_12310798
      I propose the following solution:

      — CachedConnectionManager.java.orig 2005-11-22 02:10:41.000000000 +0200
      +++ CachedConnectionManager.java 2007-09-04 18:42:48.000000000 +0300
      @@ -544,13 +544,13 @@
      try
      {
      Transaction tx = tm.getTransaction();

      • if (TxUtils.isActive(tx))
        + if (tx != null)
        {
        TransactionSynchronizer.lock(tx);
        try
        {
        CloseConnectionSynchronization cas = (CloseConnectionSynchronization) TransactionSynchronizer.getCCMSynchronization(tx);
      • if (cas == null && createIfNotFound)
        + if (cas == null && createIfNotFound && TxUtils.isActive(tx))
        {
        cas = new CloseConnectionSynchronization();
        TransactionSynchronizer.registerCCMSynchronization(tx, cas);

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                adrian.brock Adrian Brock
                Reporter:
                olegnitz Oleg Nitz
              • Votes:
                1 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: