commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: [DBCP] AbandonedTrace - Connection Recovery
Date Mon, 21 Jul 2003 03:06:48 GMT
Noel J. Bergman wrote:
> It appears clear that there are two camps, each with fairly strong views.
> Personally, I believe that both camps can be accomodated in a way that
> should satisfy both.
> DBCP should focus on core pooling behavior related to connections and
> prepared statements, and leave policy issues to specialized subclasses.  If
> DBCP is clean, without any reclaiming of connections and properly setup to
> be subclassed, including subclassing a delegating connection, then whomever
> needs a specialized connection pool that reclaims connections based upon
> some policy can do so.
> DelegatingConnection, and the rest of the core objects should be pure and
> focused only on the necessary behavior to implement connection pooling.
> DBCP should focus on what has to happen when a connection is requested or
> returned.  Behavior, not policy, should be the watch word.  There is enough
> behavior to deal with related to connection pooling, including ensuring the
> proper state of pooled connections.
> Some of the "AbandonedTrace" behavior is still necessary to implement the
> JDBC specification.  Connections still need to track outstanding statements
> and results sets, which are closed by Connection.close().  However, the
> "abandoned" semantic is not in the specification.  It is perfectly
> permissible to leave a ResultSet or Statement open, and expect the
> connection to close it.  Nor is it necessary for DBCP to track leaks,
> regardless of whether or not it is implementing recovery.  Both of that
> behavior can be implemented by specialized subclasses.  DBCP may wish to
> provide abstract classes that facilitate specialization.

I fess up, I am the guilty party who added the ability to trace abandoned
connections and recover them. ;-)

Sorry to jump in late on this.  I have been busy with other things.

The motivation behind this was to allow a servlet container to continue
operating normally even if you have customers who either wrote crappy
code themselves or hired consultants who wrote crappy code.  This helps
improve servlet container availability in these situations and logs
information which can help track down the problem.  The only solution
when crappy code causes problems with exhausting the connection pool is
to stop and restart the container.  I don't know about you, but I don't
like getting paged in the evening or on weekends due to someone elses
crappy code.

I can appreciate the arguments for a cleaner DBCP implementation.
And refactoring its design to clean it up can be a good thing.

But the ability to track and close abandoned db connections is vital
from my perspective.  I strongly urge that the ability to do this
be retained in DBCP.  If the refactored core of DBCP allows this
by subclasssing it, great.  But those sub classes to support this
should be released with DBCP.



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

View raw message