commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Date Thu, 24 Jul 2003 08:15:09 GMT
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: 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