Dirk, I see your point about helping to detect poor logic, but wouldn't it be better to just print out a warning log message stating that the connection was double-closed, perhaps with a stack trace? That way, the code which would be legal (according to the javadoc) will still operate. This was a problem for me when I was converting some legacy code to use DBCP, and the common programming pattern in place resulted in just about every connection being double-closed. So, as soon as I set up DBCP, exceptions are being thrown everywhere, and the program just wouldn't work until I went and fixed each individual case, which was a large bit of refactoring. If DBCP had just printed out a warning message instead, then I could have tracked them down at my leisure.
I also think that it does contradict the interface to throw an exception in a situation that is expressly documented in the interface to be a no-op. Thanks, --Austin > Hi Austin, > > We know about the double close and the javadoc allows it but it also allows > SQLExceptions to be > thrown. > > Personally I think the current behavior is useful because it helps detect the poor > logic to close a > connection twice. > This has been the behavior since 1.0. > > > -- Dirk Austin Mills wrote: Hello all, I just started using DBCP and am pretty happy with it, but I've come across something that seems a bit strange to me. When a connection received from the DBCP pool has close() called upon it two times, on the second call, it will throw an SQL exception such as: java.sql.SQLException: Connection is closed. at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:174) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:179) at... (my code from here on) After browsing the docs/archives, this seems to be intended as a feature (or at a fix to a previous bug, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22079 ) and I can understand that, as it's generally indicative of poor logic to close a connection twice. This is, however, directly in contradiction of the interface java.sql.Connection, which states in the javadocs of the close() method: "Calling the method close on a Connection object that is already closed is a no-op." Functionally, what this means is that when a developer has an existing codebase where connections are double-closed (bad, yes, but legal within the interface definition), he can switch to the DBCP pooling system from another system and end up having exceptions thrown from double-closing Connections (as I did). My question is, is this a conscious decision on the part of the developers to break away from that point in the interface definition? Or is it just something that was overlooked in the interests of writing better code? My hunch is that I should write this up as a bug in Bugzilla, but I wanted to get the opinions of the developers. Thanks, Austin Mills Development SensorLogic | M2M made easy. 972-934-7375 x2107 972-934-7376 (fax) [EMAIL PROTECTED] www.sensorlogic.com Join SensorLogic at Wireless Sensing Solutions 2004 and receive a 25% discount on the conference program when you register online at http://www.wssconference.com/live/40/ with SensorLogic priority code: B0104. Austin Mills Development SensorLogic | M2M made easy. 972-934-7375 x2107 972-934-7376 (fax) [EMAIL PROTECTED] www.sensorlogic.com Join SensorLogic at Wireless Sensing Solutions 2004 and receive a 25% discount on the conference program when you register online at http://www.wssconference.com/live/40/ with SensorLogic priority code: B0104. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
