commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [DBCP] AbandonedTrace - Connection Recovery
Date Wed, 23 Jul 2003 14:21:16 GMT


 /**
     * 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


Mime
View raw message