commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [DBCP] getNumActive() returns a negative value
Date Tue, 02 Sep 2003 16:24:12 GMT


Below, I've copied the code listing from the Tomcat How-To.  Notice, if all
goes well, the connection is closed and set to null in the try block.  If
that's the case, the 'if (conn != null)' check, in the finally block, will
be false and the connection won't be closed a second time.  The only time
the connection will be closed in the finally block is if some Exception
gets thrown before the call to conn.close() in the try block, in which case
the first conn.close() will not have been called.  In short, if you copied
this code, your connections shouldn't be getting closed twice.  That being
said, I'm not sure what the utility of closing the Connection in two places
really is; why not just do it in the finally block?

  Connection conn = null;
  Statement stmt = null;  // Or PreparedStatement if needed
  ResultSet rs = null;
  try {
    conn = ... get connection from connection pool ...
    stmt = conn.createStatement("select ...");
    rs = stmt.executeQuery();
    ... iterate through the result set ...
    rs = null;
    stmt = null;
    conn.close(); // Return to connection pool
    conn = null;  // Make sure we don't close it twice
  } catch (SQLException e) {
    ... deal with errors ...
  } finally {
    // Always make sure result sets and statements are closed,
    // and the connection is returned to the pool
    if (rs != null) {
      try { rs.close(); } catch (SQLException e) { ; }
      rs = null;
    if (stmt != null) {
      try { stmt.close(); } catch (SQLException e) { ; }
      stmt = null;
    if (conn != null) {
      try { conn.close(); } catch (SQLException e) { ; }
      conn = null;


"Aitor Imaz" <> on 09/02/2003 08:51:00 AM

Please respond to "Jakarta Commons Users List"

To:    <>
Subject:    [DBCP] getNumActive() returns a negative value

I'm using DBCP (v1.0) within a Struts 1.1 webapp and after performing a
stress test, a call to the getNumActive() method always returns a
negative value. A similar call to getNumIdle() returns the correct value
for that property. I wonder if this has to do with the way I return the
connections to the pool.

I'm using the same structure described in a Tomcat document
s-howto.html#Common%20Problems), because before that I found random
closed connections when running my webapp.

As you can see, the connection is closed twice, but the person who wrote
the document claims this is the proper way to clean things up, I haven't
found any other text that refutes it. Maybe this way of closing
connections twice is creating a race condition that makes the active
connection counter act randomly. I found there is a bug report
( covering the
race condition issue, but using the latest nightly build doesn't seem to
work either. I get random "java.sql.SQLException: Already closed."
exceptions. This seems to be the normal behaviour if the webapp is
trying to close a connection twice (albeit quite annoying, because AFAIK
the JDBC spec doesn't mandate exceptions be thrown but a no-op instead).
Some other times my database (sapdb) driver complaints that the
connection is closed
( SAP DBTech
JDBC: Object is closed) when if I'm not wrong the mentioned patch should
have corrected that behaviour.

I have plenty of connections allocated for the pool so this shouldn't be
an issue.

Is the model the Tomcat document presents correct? Should I only close
the connection in one place (for example, the finally clause)? Is it
creating a race condition and consequently making the active connection
counter behave randomly?

I hope someone can help me.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message