commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Verbeeck <dirk.verbe...@pandora.be>
Subject Re: [DBCP] getNumActive() returns a negative value
Date Tue, 02 Sep 2003 21:26:05 GMT
Negative getNumActive() is a clear sign that you are returning your 
connections to the pool twice.
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





Mime
View raw message