commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <>
Subject RE: [DBCP] AbandonedTrace - Connection Recovery
Date Wed, 23 Jul 2003 08:23:36 GMT
> I did a lot of this kind of bugs myself too and it is very 
> trivial to fix.
> 1. Set maxConnections to 1 for testing


> 2. Use lazy decorator for connection to throw exeption from "close"
> 3. Use "find/replace" to remove all "}finally{ connection.close(); }"
> 4. Store decorator in ThreadLocal and close connection in 
> single place per application.

Ahhh now I see what you are doing - this then requires maxConnectionsInPool
== max threads or the app will break under heavy load, not IMO a good design
> I am sure we are talking about web applications and it is very trivial to
> close connection in controler or to implement Filter for Model 1  web
> application, but this solution works for any kind of 
> applications, I use it for JMS too.

The simplest way to avoid requiring the use of such approaches or of
abandonded connection reclamation is to do the exacty oppositie of 3. any
call which genuinely brings a connection into active play (get from pool,
use datasource, DriverManager etc should include a finally block closing the
resource. If this is followed there will be no problems with leaks and an
optimal put back in pool strategy is possible. If there is no need for a
call to open a connection it is not opened (you could achieve this on your
method with the lazy decorator but at the cost of maintaing it).

finally blocks are one of the great benefits of using a modern high level
language - use them.

If I am reviewing someone else's code I search for every connection opening
and statement creating and require a corresponding finally block to close
them. If I am responsible for quality gating outsourced code I do the same.

If we purchase a library that does this I will likely never recommend we use
it or that company again...

I see why people desire a stop gap solution but as this message indicates -
shortcuts to doing proper resource management will be looked for and
(ab)used if they exist - frequently incorrectly...

The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

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

View raw message