I'm still getting random ObjectIsClosedExceptions once in a while using the nightly build (31/8), although not very often. If I'm not wrong this nightly build uses the wrapper that checks for double-closing connections, so I can't understand why I'm still getting a negative value when I call getNumActive(). Shouldn't the patch deal with this issue?
I'm doing what the Tomcat example says, except that inside the catch block I am closing the resultset and statement and doing a rollback on the transaction (and setting the connection to null). I wonder if this has something to do with the negative numActive value. Should I rely on the finally block instead? I see your point on returning an SQLException indicating something is wrong, but the problem is I'm logging the exceptions and my log file grows considerably as I'm getting lots of "Already closed" SQLExceptions. I guess this is more of an issue with the way I save the thrown exceptions, though. I'm afraid we haven't thoroughly load-tested our application (and therefore DBCP). I am using a load test simply to simulate the race condition and make the app fail. Cheers, Aitor Dirk Verbeeck wrote: >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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
