Juozas, I don't intend to continue to "debate" this issue with you, you are obviously not open to considering anything other than your own point of view, your comments are rude and show little respect to the other participants in the discussion. I have already suggested that you provide some suggestions of your own, you have chosen to do nothing but criticise every attempt made to reach a compromise. d.
> 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" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > 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 > 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] > > > > > --------------------------------------------------------------------- > 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]
