commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <>
Subject [dbcp] Connection.close() implementation issues [was: Jumping in...]
Date Wed, 08 Mar 2006 07:00:48 GMT
On 3/7/06, Phil Steitz <> wrote:
> There is a growing backlog of bugs open against [dbcp].  Unless other
> committers object, I am going to jump in and start committing patches
> and develop a maintenance release plan.  I plan to start with
> I would appreciate any feedback that community members have on
> prioritization of open tickets.  Also, as always, tickets with patches
> and test cases are likely to get addressed quicker and comments /
> testing / feedback are always welcome.
> Any help from other commons committers, even if just in the form of
> screams, will be most appreciated.

I've looked into some, as you can tell from my retracted bugzilla
comment and I think I've found a large source of the problems.

The method Connection.close() interface states: "Calling the method
close on a Connection object that is already closed is a no-op."

This is violated in a number of places:
* throws an exception when close is called
and it's already closed. It should be replaced with a line similar to:
try {
  if (!hasBeenReturnedToPool) {
    hasBeenReturnedToPool = true;
} catch (Exception e) {
   // ignored

* calls assertOpen() which throws an
SQLException when it isn't open. This line should be removed.

* the call to checkOpen() is like the call
to assertOpen() mentioned above and should be removed.

* PoolingDriver:258: another call to checkOpen(), same solution as before.

* another call to checkOpen(), same solution
as before.

Someone should also audit:
* make sure the call to passivate() is
fine being called more than once.

Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message