Commons Dbcp
  1. Commons Dbcp
  2. DBCP-193

BasicDataSource returns negative values for NumActive when Oracle Driver Connection#isClosed return true (End of file communication on CHannel)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.2.1, 1.2.2
    • Fix Version/s: 1.3
    • Labels:
      None
    • Environment:

      Windows / Oracle 10G JDBC driver / Oracle 10G / JDK 1.4.2_08 / Commons-dbcp-1.2.1.jar / COmmons-pool-1.3.jar

      Description

      Hello,
      This bug occurs if the following conditions are met:
      A End of File communication on CHannel occurs
      Oracle Driver 10G will return true for Connection#isClosed()

      Related bugs:
      DBCP-3
      DBCP-28

      Case 1:
      The client calls isClosed() before closing a connection since commons-dbcp does not allow double close without throwing (see DBCP-3)
      => The problem is that since he calls isClosed, he encounters the same bug reported in DBCP-28 because conn.isClosed() will return true and the client will not call close.
      if (!conn.isClosed())
      {
      try{
      conn.close();
      }catch(Exception e){}
      }
      see what happens if the isClosed() in PoolableConnection returns true : ShowsLeaksIfCheckForIsClosed.java

      Case2:
      The client tries to find a solution, and calls conn.close() without checking isClosed(), but the problem is that the client is in a Persistence fwk and the client may have already called close, so he ends up calling close() twice, see what happens if the isClosed() in PoolableConnection returns true : ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java

      1. TestUtils.java
        1 kB
        Philippe Mouawad
      2. ShowsLeaksIfCheckForIsClosed.java
        2 kB
        Philippe Mouawad
      3. ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
        2 kB
        Philippe Mouawad

        Issue Links

          Activity

          Philippe Mouawad created issue -
          Hide
          Philippe Mouawad added a comment -

          To work, the call isClosed() in PoolableConnection.java must return true (Case of an End of communication on channel in Oracle):
          public synchronized void close() throws SQLException {
          boolean isClosed = false;
          try {
          isClosed = isClosed();

          Show
          Philippe Mouawad added a comment - To work, the call isClosed() in PoolableConnection.java must return true (Case of an End of communication on channel in Oracle): public synchronized void close() throws SQLException { boolean isClosed = false; try { isClosed = isClosed();
          Philippe Mouawad made changes -
          Field Original Value New Value
          Attachment ShowsLeaksIfCheckForIsClosed.java [ 12336773 ]
          Attachment TestUtils.java [ 12336774 ]
          Attachment ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java [ 12336772 ]
          Phil Steitz made changes -
          Fix Version/s 1.3 [ 12311977 ]
          Hide
          Henri Yandell added a comment -

          Changing links to just be the keys so we get the nice strikethroughs to show things are fixed.

          Show
          Henri Yandell added a comment - Changing links to just be the keys so we get the nice strikethroughs to show things are fixed.
          Henri Yandell made changes -
          Description Hello,
          This bug occurs if the following conditions are met:
          A End of File communication on CHannel occurs
          Oracle Driver 10G will return true for Connection#isClosed()

          Related bugs:
          http://issues.apache.org/jira/browse/DBCP-3
          http://issues.apache.org/jira/browse/DBCP-28

          Case 1:
          The client calls isClosed() before closing a connection since commons-dbcp does not allow double close without throwing (see http://issues.apache.org/jira/browse/DBCP-3)
          => The problem is that since he calls isClosed, he encounters the same bug reported in http://issues.apache.org/jira/browse/DBCP-28 because conn.isClosed() will return true and the client will not call close.
          if (!conn.isClosed())
          {
          try{
          conn.close();
          }catch(Exception e){}
          }
          see what happens if the isClosed() in PoolableConnection returns true : ShowsLeaksIfCheckForIsClosed.java

          Case2:
          The client tries to find a solution, and calls conn.close() without checking isClosed(), but the problem is that the client is in a Persistence fwk and the client may have already called close, so he ends up calling close() twice, see what happens if the isClosed() in PoolableConnection returns true : ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
          Hello,
          This bug occurs if the following conditions are met:
          A End of File communication on CHannel occurs
          Oracle Driver 10G will return true for Connection#isClosed()

          Related bugs:
          DBCP-3
          DBCP-28

          Case 1:
          The client calls isClosed() before closing a connection since commons-dbcp does not allow double close without throwing (see DBCP-3)
          => The problem is that since he calls isClosed, he encounters the same bug reported in DBCP-28 because conn.isClosed() will return true and the client will not call close.
          if (!conn.isClosed())
          {
          try{
          conn.close();
          }catch(Exception e){}
          }
          see what happens if the isClosed() in PoolableConnection returns true : ShowsLeaksIfCheckForIsClosed.java

          Case2:
          The client tries to find a solution, and calls conn.close() without checking isClosed(), but the problem is that the client is in a Persistence fwk and the client may have already called close, so he ends up calling close() twice, see what happens if the isClosed() in PoolableConnection returns true : ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
          Hide
          Henri Yandell added a comment -

          Does DBCP-28 being fixed invalidate this issue as a problem?

          Show
          Henri Yandell added a comment - Does DBCP-28 being fixed invalidate this issue as a problem?
          Hide
          Phil Steitz added a comment -

          No (Hen), I think this remains a problem and will be fixed when we fix close semantics in 1.3

          Show
          Phil Steitz added a comment - No (Hen), I think this remains a problem and will be fixed when we fix close semantics in 1.3
          Henri Yandell made changes -
          Link This issue depends upon DBCP-3 [ DBCP-3 ]
          Hide
          Henri Yandell added a comment -

          From the description - when DBCP-3 is resolved, it looks like this issue becomes a non-issue.

          Show
          Henri Yandell added a comment - From the description - when DBCP-3 is resolved, it looks like this issue becomes a non-issue.
          Hide
          Phil Steitz added a comment -

          Related multiple close bugs are fixed, so this issue should be resolved.

          Show
          Phil Steitz added a comment - Related multiple close bugs are fixed, so this issue should be resolved.
          Phil Steitz made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Henri Yandell made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          381d 11h 9m 1 Phil Steitz 29/Jul/07 16:39
          Resolved Resolved Closed Closed
          239d 16h 32m 1 Henri Yandell 25/Mar/08 08:11

            People

            • Assignee:
              Unassigned
              Reporter:
              Philippe Mouawad
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development