commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <>
Subject RE: [DBCP] AbandonedTrace - Connection Recovery
Date Tue, 22 Jul 2003 12:34:24 GMT
I would disagree on one point. The idea of logging when a connection is
closed due to garbage collection finalization strikes me as a good one
(assuming the pool used is using a weakly referenced mapping otherwise
garbage collection release of resources is going to be a real bummer).

this kind of thing almost certainly indicates a failure of application code
or the library - both are things that are worth knowing about (my moneys on
the app :¬).

I fully agree with no attempt to 'recover' any sort of connection but it
would assist debugging of legacy apps and other people's code if you could
spot where the connection came from...

Of course you could just take the view that p6spy does what you need and
provide a pointer in that direction, commiters choice really...


> -----Original Message-----
> From: Juozas Baliuka [] 
> Sent: 22 July 2003 13:16
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> I do not think it is good idea to maintain any kind of public API for
> "abandoned connections", It is garbage,
> If application or server is not broken, it doe's not need workarounds.
> Workarounds can not help for broken applications any way, it 
> is a useless
> stuff and it infects code with "Observers".
> As I understand it, people want to move problems from crappy 
> applications to
> commons and to blame jakarta, but I think it is better
> to use  the rigth way solve problems and a lot of solotions 
> was proposed on
> this list too.
> > Serge et al,
> >
> > Further to my suggestion about using the Observer pattern for event
> > notification w.r.t. point 4 (below) I forgot to mention 
> that it also has
> the
> > benefit of offering a compromise in the pro/anti recovery debate.
> >
> > Existing contentious code designed to reclaim or test 
> connections need not
> > be retired as it could still be made available re-factored into a
> listener,
> > and attached at runtime by the user. Users can use, extend or ignore
> DBCP's
> > own listeners at their discretion shifting the decision from the
> developers
> > to the users where, judging by the debate, it probably belongs.
> >
> > It also follows that DBCP need not then impose a single 
> Jakarta-approved
> > strategy, but could easily be shipped with a number of 
> implementations of
> > different strategies, chosen between and attached at 
> runtime by the user
> or
> > by DBCP itself in response to configuration settings.
> >
> > > 4. Provide some kind of extensible connection object that 
> could allow
> > > someone to add their own (possibly included but optional) 
> way to recover
> > > abandoned connections.
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

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

View raw message