Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <007b01c350db$31308870$0111010a@user>
From: "Juozas Baliuka" <baliuka@centras.lt>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: 
 <20030722141011.86734.qmail@web20709.mail.yahoo.com><3F1D5EB0.7040104@mail.more.net>
  <00de01c35076$a2d3fa30$0111010a@user>
 <1058931338.1603.266.camel@localhost.localdomain>
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
Date: Wed, 23 Jul 2003 07:28:04 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-4"
Content-Transfer-Encoding: 7bit


>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org