You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Danny Angus <da...@apache.org> on 2003/07/24 10:15:09 UTC
[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: 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
Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Posted by Juozas Baliuka <ba...@centras.lt>.
Sorry, if somebody found something personal in my messages, I was not going
to personalize "connection leak" problem.
My suggestion is very clear, to remove workarounds from pool and to
implement resource management component.
Doe's somebody proposed the way to detect connection leak ? Is it bad
compromise, if nobody knows a solution ?
> 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" <da...@apache.org>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > 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: 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Posted by Danny Angus <da...@apache.org>.
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" <da...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> 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: 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Posted by Juozas Baliuka <ba...@centras.lt>.
-1
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" <da...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
Posted by David Graham <gr...@yahoo.com>.
+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 <da...@apache.org> 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: 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
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org