In v1.0 this was possible due to a race contition in close (issue 16987) like you found.
The problem with the SAP jdbc driver exception can be a result of
http://issues.apache.org/bugzilla/show_bug.cgi?id=22079 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22079>
Both issues are solved in the latests build.
Are you getting the ObjectIsClosedException in the nightly build ?
Like Jamie said, the tomcat example is correct, see also my examples...
I know that the spec specifies a no-op but a SQLException is allowed and shows where something goes wrong.
The behaviour is unchanged since 1.0 but now you will get it always when returning a connection twice.
I'm very interested in the stability and speed results. Can you compare v1.0 and the latest under high load?
Cheers Dirk
Aitor Imaz wrote:
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
