commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <>
Subject Re: [DBCP] AbandonedTrace - Connection Recovery
Date Wed, 23 Jul 2003 03:35:36 GMT
On Tue, 2003-07-22 at 10:28, Juozas Baliuka wrote:
> > I agree that this is an education/policy issue.  But sometimes you need
> > a stop gap solution to keep something running while the customer fixes
> > the problem.
> >
> > I would like to see this stop gap solution included with the DBCP release.
> > Along with quality docs on how to properly use a db connection pool and
> > a big disclaimer that the recovery of abandoned connections should only
> > be used as a stop gap in an emergency until the customer has time to
> > fix their code.
> Try to implement yourself and I am sure the time to fix a problem will mean
> forever
> and crappers will blame you then server or app will crache. Do you want
> to blame apache for this code ? This problem redirection will not help, but
> if you want, you can maintain this crap yourself,
> but do not try to redirect this problem to apache please.

This attitude is not very helpful.  I don't see how dbcp supplying the
ability to configure a connection pool to reclaim connections is that
big of an issue.  It adds code complexity, but if the implementation is
modified so that it is not central to the rest of the code and the
critical bug entered against the current implementation is solved, we
should allow it as part of the release.

I was for the removal of this code, assuming the contributor had
abandoned it and it had bugs no one else wanted to fix.  But it is a
perfectly valid feature and the original developer is stating he is
willing to rewrite it.  

Is it not possible for many databases to configure an idle timeout?  I'm
pretty sure this kind of ability is to handle the same sort of badly
written client code.  Does mysql get blamed if a poorly written
application loses a connection because it leaked it and did not close
it, but mysql reclaims it.  How about if the db admin sets the timeout
too low and some normal running process ends up corrupting the data
because it held a connection too long.  I don't think so; it is
important that the configuration options are set appropriately for the
apps that will be using the database/connection pool.  We are not taking
on any responsibility for someone's crappy code by such a feature.

Consider that you are using dbcp as your connection pool and your code
is error-free.  You are awaiting a feature from a
partner/subcontractor.  The feature runs some reporting queries on an
interval of 15 minutes and it is known that the queries generally take
about a minute.  It turns out the partners code is flawed and you are
going to lose money, if you have to wait for a fix and start integration
testing again after a delay.  There might be all sorts of other remedies
to this, but being able to configure the pool to recover the connections
in the pool being used by the partners code would be optimal, imo.  You
can then just continue, or worse case immediately start over on, your
integration testing.

Features related to connection management are appropriate in a
connection pool.  Is it inappropriate for tomcat to allow an admin to
configure a security policy, since well written code will not do
anything it shouldn't?

On the implementation.  I have not looked closely at the current
implementation as it is not used by the pool that I added to dbcp and I
was trying to start it as a simple implementation of the latest
specification.  But it would seem an implementation of this should just
maintain a reference to Connection objects that it hands out and then
after the allowed time period, it should call Connection.close().  The
current jdbc specification states that a Connection object should not be
usable after Connection.close() is called and the jdbc2pool
implementation does not allow the Connection object to be used after
close is called.  Note that implementation is not perfect in that it
needs to use wrapper implementations of Statement and ResultSet.  But
the idea is that once Connection.close() is called it should be safe for
the pool to use the PooledConnection, which represents the physical
connection, to create another Connection object which it can hand out. 
It doesn't seem like an implementation that just calls
Connection.close() needs to be that coupled to the rest of the pool code
and a simple event/listener model is not likely to add a bug to the main

Why is this such a contentious issue?

john mcnally

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

View raw message