commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <>
Subject Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Date Thu, 24 Jul 2003 17:20:18 GMT
I  do not think it is possible to detect connection leak in pool.
!ownerThread.isAlive() && isOpen or weakReference is in referenceQueue  is
100% connection leak,  I have tested this workaround in my crappy
applications, I found it is a very dangerous "feature" and doe's not help to
fix application .
Nobody can prove this way can help and nobody has proposed a good way to
detect a  leak and good place for
"fireOnConnectionLeak(ConnectionLeakEvent)" and server can hung before to
fire this event. It looks like we have nothing to implement, if we can not
to detect leak to fire  event.
But sandbox is open for R&D.

----- Original Message -----
From: "Danny Angus" <>
To: "Jakarta Commons Developers List" <>
Sent: Thursday, July 24, 2003 10:15 AM
Subject: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace -
Connection Recovery)

> Well I never,
> There's been a lot of talk generated by my innocent proposal of using the
> Observer pattern, or in more java-esque terms events and listeners to
> at a compromise in the Connection Recovery War. I'd like to clarify some
> points raised.
> In the first place to address the criticism of any compromise being
> by Juozas, this was intended not to appeal to one camp or the other, but
> be a neutral proposal which would accomodate both modes of use.
> There is nothing in the addition of an event model that should offend
> camp, and properly impelemented users who don't choose to listen for
> should not notice any impact on performance.
> Secondly, to address Craig's opinion that we shoudl abandon connection
> recovery altogether, I proposed that the existing recovery code be
> refactored to be usable as a listener in the event model because there
> some users, and some vocal supporters and I would like to think that this
> community is not so arrogant that we would remove support for them without
> phaseing it out gradually. The listener implementing connection recovery
> could be immediately deprecated with text to explain why we don't like it,
> and scheduled for removal at the next release, giving people time to make
> other arrangements (probably just fork it :) .
> Third there are *way* more uses for this than for supporting the forceable
> recovery of connections, for instance this could be used to log and trace
> pool activity allowing people to attach tools which will help them to
> improve their code. It really is much more than just a way in which users
> can avoid the responsibility of handling connections correctly.
> Finally it allows the DBCP project to have a finite scope. By providing an
> API for the attachment of additional functionality we would allow DBCP to
> encapsulate JDBC Connection pooling, the implementation would not be the
> concern of users nor necessarily of the majority of implementors of
> listeners. DBCP could move towards maturity and low maintenance without
> restricting the creation of new behaviours and tools.
> d.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message