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 (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-example 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 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16987) 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 (com.sap.dbtech.jdbc.exceptions.ObjectIsClosedException: 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. TIA, Aitor