+1 on a listener model but let's not rule out using the Strategy pattern as well. They both may come in handy.
David --- Danny Angus <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
