RE: DBCP: Question about throwing an exception when Connection.cl ose() is called twice

["Botelho, Mauro" <Ma...@turner.com>]

Dirk,

I agree that the behavior is useful, but it gets in the way when you are moving a legacy application from other connection pools to DBCP.

Besides, except for an extra method call, closing a resource twice causes no harm, right?

So I think that we should stick with the specification and allow the connection to be closed twice.

Mauro

-----Original Message-----
From: Dirk Verbeeck [mailto:dirk.verbeeck@pandora.be]
Sent: Sunday, September 19, 2004 2:38 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP: Question about throwing an exception when
Connection.close() is called twice


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)
> amills@sensorlogic.com
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org