commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <>
Subject Re: [DBCP] AbandonedTrace - Connection Recovery
Date Wed, 23 Jul 2003 05:28:04 GMT

> 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.

Have you tried to solve problems this way ? Is it tested solution and can be
used for "high quality software" ?
Try to implement and test anti patterns at home first.

  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.

It is not a feature too, It breaks transactions, I do not believe it
supports "autoreconnect"
if transactions are enabled.

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
> code.
> Why is this such a contentious issue?
> john mcnally
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message