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: <002801c35125$af1785a0$a901a8c0@juozas>
From: "Juozas Baliuka" <baliuka@mwm.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>
 <3F1E861A.8090201@mail.more.net>
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
Date: Wed, 23 Jul 2003 16:21:16 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


 /**
     * Get a db connection from the pool.
     *
     * If removeAbandoned=true, recovers db connections which
     * have been idle > removeAbandonedTimeout.
     *
     * @return Object jdbc Connection
     */

As I remember we have decided to log stack trace, but not to break pool.
Is this code released as commons component ?


----- Original Message -----
From: "Glenn Nielsen" <glenn@mail.more.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, July 23, 2003 2:56 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery


> John McNally wrote:
>
> [snip]
>
> >
> > 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.
> >
>
> The current implementation recover's the abandoned connection based
> on an inactivity timeout.  So it has to track the last time the
> connection was used.  This more tightly couples it to DBCP.
>
> Regards,
>
> Glenn
>
>
> ---------------------------------------------------------------------
> 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