commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <>
Subject Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Date Thu, 24 Jul 2003 13:39:07 GMT
+1 on a listener model but let's not rule out using the Strategy pattern
as well.  They both may come in handy.


--- Danny Angus <> wrote:
> 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
> arrive
> 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
> levelled
> by Juozas, this was intended not to appeal to one camp or the other, but
> to
> be a neutral proposal which would accomodate both modes of use.
> There is nothing in the addition of an event model that should offend
> either
> camp, and properly impelemented users who don't choose to listen for
> events
> 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
> *are*
> 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:

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

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

View raw message