[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]
RE: [DBCP] AbandonedTrace - Connection Recovery
-Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 12:52 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Logging is useless in this case, Such a statement seems ludicrous The relative merits of including support for recovery of connections or not aside; The logging of cases where poor coding/design/external libraries leaks an expensive resource with no impact to normal usage is IMHO an always useful feature... it is not a problem if it doe's not inspire crap like autorecovery, but it was a mistake too and this dicussion proves it, does not it ? I'm sorry if I'm interpreting this wrong but are you implying that the facility which logs such events occuring would encourage the use of maladaptive recovery strategies long term rather than fixing the problem at source? his is somewhat like saying an error report from a Junit test encourages people to stop unit testing... Attempting to return to the original topic I would very much like the functionality described above for finalized connections available in the official DBCP project, if this is by an Observer or Strategy plugin all the better. Matt ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
+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]
Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
-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 RD. - 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]
Re: [DBCP] Event/Listener proposal (was .. RE: [DBCP] AbandonedTrace - Connection Recovery)
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 RD. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I did a lot of this kind of bugs myself too and it is very trivial to fix.
1. Set maxConnections to 1 for testing
2. Use lazy decorator for connection to throw exeption from close
3. Use find/replace to remove all }finally{ connection.close(); }
4. Store decorator in ThreadLocal and close connection in single place per
application.
I am sure we are talking about web applications and it is very trivial to
close connection in controler or to implement Filter for Model 1 web
application, but this solution works for any kind of applications, I use it
for JMS too.
BTW
it is not a very big overhead in the most of my use cases (application and
DB on the same machine or LAN) if pool opens a new connection per thread
without autoreconnects and any kind of workarounds.
Juozas Baliuka wrote:
I like innovations, but try to implement and test it at home please.
I am sure there are not so many situations in the real world need this
feature.
It takes a few minutes to find connection leak and to fix it in any
applications, doe's not it ?
It does not.
I have 2 new clients in the past 3 months (one medium, and one huge
highly publicized screwed-up government project) that both have
connection leak issues that they have been working at for a long time.
--
Serge Knystautas
President
Lokitech software . strategy . design http://www.lokitech.com/
p. 1.301.656.5501
e. [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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Connection Recovery can not help to solve resouce leak and performance problems, but It can produce more problems. I can not let to break stable component to prove it. - Original Message - From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:34 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). this kind of thing almost certainly indicates a failure of application code or the library - both are things that are worth knowing about (my moneys on the app :¬). I fully agree with no attempt to 'recover' any sort of connection but it would assist debugging of legacy apps and other people's code if you could spot where the connection came from... Of course you could just take the view that p6spy does what you need and provide a pointer in that direction, commiters choice really... Matt -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 22 July 2003 13:16 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - 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] ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - 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]
RE: [DBCP] AbandonedTrace - Connection Recovery
I did a lot of this kind of bugs myself too and it is very
trivial to fix.
1. Set maxConnections to 1 for testing
useful
2. Use lazy decorator for connection to throw exeption from close
???
3. Use find/replace to remove all }finally{ connection.close(); }
??!?!?!?!
4. Store decorator in ThreadLocal and close connection in
single place per application.
Ahhh now I see what you are doing - this then requires maxConnectionsInPool
== max threads or the app will break under heavy load, not IMO a good design
decision.
I am sure we are talking about web applications and it is very trivial to
close connection in controler or to implement Filter for Model 1 web
application, but this solution works for any kind of
applications, I use it for JMS too.
The simplest way to avoid requiring the use of such approaches or of
abandonded connection reclamation is to do the exacty oppositie of 3. any
call which genuinely brings a connection into active play (get from pool,
use datasource, DriverManager etc should include a finally block closing the
resource. If this is followed there will be no problems with leaks and an
optimal put back in pool strategy is possible. If there is no need for a
call to open a connection it is not opened (you could achieve this on your
method with the lazy decorator but at the cost of maintaing it).
finally blocks are one of the great benefits of using a modern high level
language - use them.
If I am reviewing someone else's code I search for every connection opening
and statement creating and require a corresponding finally block to close
them. If I am responsible for quality gating outsourced code I do the same.
If we purchase a library that does this I will likely never recommend we use
it or that company again...
I see why people desire a stop gap solution but as this message indicates -
shortcuts to doing proper resource management will be looked for and
(ab)used if they exist - frequently incorrectly...
Matt
**
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
a viewpoint I can sympathise with but I don't see how that effects the use case I outlined below. This is not recovery, it is logging that resources are not being cleaned up properly... -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 09:19 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Connection Recovery can not help to solve resouce leak and performance problems, but It can produce more problems. I can not let to break stable component to prove it. - Original Message - From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:34 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). this kind of thing almost certainly indicates a failure of application code or the library - both are things that are worth knowing about (my moneys on the app :¬). I fully agree with no attempt to 'recover' any sort of connection but it would assist debugging of legacy apps and other people's code if you could spot where the connection came from... Of course you could just take the view that p6spy does what you need and provide a pointer in that direction, commiters choice really... Matt -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 22 July 2003 13:16 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - 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] ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - 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] ** The information transmitted herewith is sensitive information intended only for use by the individual or entity
Re: [DBCP] AbandonedTrace - Connection Recovery
You misunderstand me. http://www.springframework.org/ I have never used this
framework, but I use the same ideas.
I did a lot of this kind of bugs myself too and it is very
trivial to fix.
1. Set maxConnections to 1 for testing
useful
2. Use lazy decorator for connection to throw exeption from close
???
3. Use find/replace to remove all }finally{ connection.close(); }
??!?!?!?!
4. Store decorator in ThreadLocal and close connection in
single place per application.
Ahhh now I see what you are doing - this then requires
maxConnectionsInPool
== max threads or the app will break under heavy load, not IMO a good
design
decision.
I am sure we are talking about web applications and it is very trivial
to
close connection in controler or to implement Filter for Model 1 web
application, but this solution works for any kind of
applications, I use it for JMS too.
The simplest way to avoid requiring the use of such approaches or of
abandonded connection reclamation is to do the exacty oppositie of 3. any
call which genuinely brings a connection into active play (get from pool,
use datasource, DriverManager etc should include a finally block closing
the
resource. If this is followed there will be no problems with leaks and an
optimal put back in pool strategy is possible. If there is no need for a
call to open a connection it is not opened (you could achieve this on your
method with the lazy decorator but at the cost of maintaing it).
finally blocks are one of the great benefits of using a modern high level
language - use them.
If I am reviewing someone else's code I search for every connection
opening
and statement creating and require a corresponding finally block to close
them. If I am responsible for quality gating outsourced code I do the
same.
If we purchase a library that does this I will likely never recommend we
use
it or that company again...
I see why people desire a stop gap solution but as this message
indicates -
shortcuts to doing proper resource management will be looked for and
(ab)used if they exist - frequently incorrectly...
Matt
**
The information transmitted herewith is sensitive information intended
only
for use by the individual or entity to which it is addressed. If the
reader
of this message is not the intended recipient, you are hereby notified
that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
-
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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Logging is useless in this case, it is not a problem if it doe's not inspire crap like autorecovery, but it was a mistake too and this dicussion proves it, does not it ? - Original Message - From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 10:50 AM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery a viewpoint I can sympathise with but I don't see how that effects the use case I outlined below. This is not recovery, it is logging that resources are not being cleaned up properly... -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 09:19 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Connection Recovery can not help to solve resouce leak and performance problems, but It can produce more problems. I can not let to break stable component to prove it. - Original Message - From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:34 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). this kind of thing almost certainly indicates a failure of application code or the library - both are things that are worth knowing about (my moneys on the app :¬). I fully agree with no attempt to 'recover' any sort of connection but it would assist debugging of legacy apps and other people's code if you could spot where the connection came from... Of course you could just take the view that p6spy does what you need and provide a pointer in that direction, commiters choice really... Matt -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 22 July 2003 13:16 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - 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] ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: [DBCP] AbandonedTrace - Connection Recovery
I have only had a cursory read through this - using someone elses
(hopefully better tested both in unit and real world) implementation is
better than writing your own...
...however any system attempting to remove resource cleanup responsibilites
from the developer either has to place extremely restrictive constraints on
the use or sacrifice optimal resoucre utilization.
if you don't need optimal resource use then or can handle the constraints
then by all means work within a framework - just remember that if you ever
change your situation to requiring optimal use or working outside the
constraints you have a problem.
Matt
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: 23 July 2003 11:34
To: Jakarta Commons Developers List
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
You misunderstand me. http://www.springframework.org/ I have
never used this
framework, but I use the same ideas.
I did a lot of this kind of bugs myself too and it is very
trivial to fix.
1. Set maxConnections to 1 for testing
useful
2. Use lazy decorator for connection to throw exeption
from close
???
3. Use find/replace to remove all }finally{
connection.close(); }
??!?!?!?!
4. Store decorator in ThreadLocal and close connection in
single place per application.
Ahhh now I see what you are doing - this then requires
maxConnectionsInPool
== max threads or the app will break under heavy load, not
IMO a good
design
decision.
I am sure we are talking about web applications and it is
very trivial
to
close connection in controler or to implement Filter for
Model 1 web
application, but this solution works for any kind of
applications, I use it for JMS too.
The simplest way to avoid requiring the use of such approaches or of
abandonded connection reclamation is to do the exacty
oppositie of 3. any
call which genuinely brings a connection into active play
(get from pool,
use datasource, DriverManager etc should include a finally
block closing
the
resource. If this is followed there will be no problems
with leaks and an
optimal put back in pool strategy is possible. If there is
no need for a
call to open a connection it is not opened (you could
achieve this on your
method with the lazy decorator but at the cost of maintaing it).
finally blocks are one of the great benefits of using a
modern high level
language - use them.
If I am reviewing someone else's code I search for every connection
opening
and statement creating and require a corresponding finally
block to close
them. If I am responsible for quality gating outsourced
code I do the
same.
If we purchase a library that does this I will likely never
recommend we
use
it or that company again...
I see why people desire a stop gap solution but as this message
indicates -
shortcuts to doing proper resource management will be looked for and
(ab)used if they exist - frequently incorrectly...
Matt
**
The information transmitted herewith is sensitive
information intended
only
for use by the individual or entity to which it is addressed. If the
reader
of this message is not the intended recipient, you are
hereby notified
that
any review, retransmission, dissemination, distribution,
copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this
communication in error,
please contact the sender and delete the material from your
computer.
-
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]
**
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: [DBCP] AbandonedTrace - Connection Recovery
It is true, some of resource menegement way have overhead, like Filter for
web application, it closes connection after output is sent and uses
connection too long, but it is not a problem if resources are managed by
controler, it is very trivial to handle with struts.
I use callback interface to manage prepared statements and resultsets.
http://voruta.sourceforge.net this is an exotic framework, I use it myself,
but do not recommend it for production at this time
(experimental).
I have only had a cursory read through this - using someone elses
(hopefully better tested both in unit and real world) implementation is
better than writing your own...
...however any system attempting to remove resource cleanup
responsibilites
from the developer either has to place extremely restrictive constraints
on
the use or sacrifice optimal resoucre utilization.
if you don't need optimal resource use then or can handle the constraints
then by all means work within a framework - just remember that if you ever
change your situation to requiring optimal use or working outside the
constraints you have a problem.
Matt
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: 23 July 2003 11:34
To: Jakarta Commons Developers List
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
You misunderstand me. http://www.springframework.org/ I have
never used this
framework, but I use the same ideas.
I did a lot of this kind of bugs myself too and it is very
trivial to fix.
1. Set maxConnections to 1 for testing
useful
2. Use lazy decorator for connection to throw exeption
from close
???
3. Use find/replace to remove all }finally{
connection.close(); }
??!?!?!?!
4. Store decorator in ThreadLocal and close connection in
single place per application.
Ahhh now I see what you are doing - this then requires
maxConnectionsInPool
== max threads or the app will break under heavy load, not
IMO a good
design
decision.
I am sure we are talking about web applications and it is
very trivial
to
close connection in controler or to implement Filter for
Model 1 web
application, but this solution works for any kind of
applications, I use it for JMS too.
The simplest way to avoid requiring the use of such approaches or of
abandonded connection reclamation is to do the exacty
oppositie of 3. any
call which genuinely brings a connection into active play
(get from pool,
use datasource, DriverManager etc should include a finally
block closing
the
resource. If this is followed there will be no problems
with leaks and an
optimal put back in pool strategy is possible. If there is
no need for a
call to open a connection it is not opened (you could
achieve this on your
method with the lazy decorator but at the cost of maintaing it).
finally blocks are one of the great benefits of using a
modern high level
language - use them.
If I am reviewing someone else's code I search for every connection
opening
and statement creating and require a corresponding finally
block to close
them. If I am responsible for quality gating outsourced
code I do the
same.
If we purchase a library that does this I will likely never
recommend we
use
it or that company again...
I see why people desire a stop gap solution but as this message
indicates -
shortcuts to doing proper resource management will be looked for and
(ab)used if they exist - frequently incorrectly...
Matt
**
The information transmitted herewith is sensitive
information intended
only
for use by the individual or entity to which it is addressed. If the
reader
of this message is not the intended recipient, you are
hereby notified
that
any review, retransmission, dissemination, distribution,
copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this
communication in error,
please contact the sender and delete the material from your
computer.
-
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]
**
The information transmitted herewith is sensitive information intended
only
for use by the individual or entity to which it is addressed. If the
reader
of this message is not the intended recipient, you are hereby notified
that
any review, retransmission, dissemination, distribution, copying or other
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: --- Laird J. Nelson [EMAIL PROTECTED] wrote: -Original Message- From: John McNally [mailto:[EMAIL PROTECTED] Why is this such a contentious issue? FWIW, because some users have business experience, and some do not. Those who do recognize that business *runs* on stopgap solutions. The fewer of those stopgap solutions you have to write, the better, IMHO. [SNIP] This is absolutely not a DBCP code issue; it is a management issue. Applications that leak resources should have their own separate connection pool. When they run out of connections, only that app will break and won't affect any other applications on the server. It will be much easier to debug the leak in the isolated app because DBCP won't hide it from you and you won't have to search any other apps. So, there is no need for this feature in DBCP if the above process is followed. This makes everyone's life simpler :-). A web application which leaks db connections until it exhausts its pool can impact other applications running on the app server. What happens is that the broken app ends up sucking up resources for each concurrent request being made to it which is waiting for the db connection timeout. Usually this is set to 5-10 seconds. This can suck up alot of resources. Memory, threads, etc. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Hope, Matthew wrote: I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). Using GC to log or recover an abandoned connection won't work because the connection is a member of the pool and will never be eligible for GC. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
John McNally wrote: [snip] On the implementation. I have not looked closely at the current implementation as it is not used by the pool that I added to dbcp and I was trying to start it as a simple implementation of the latest specification. But it would seem an implementation of this should just maintain a reference to Connection objects that it hands out and then after the allowed time period, it should call Connection.close(). The current jdbc specification states that a Connection object should not be usable after Connection.close() is called and the jdbc2pool implementation does not allow the Connection object to be used after close is called. Note that implementation is not perfect in that it needs to use wrapper implementations of Statement and ResultSet. But the idea is that once Connection.close() is called it should be safe for the pool to use the PooledConnection, which represents the physical connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls Connection.close() needs to be that coupled to the rest of the pool code and a simple event/listener model is not likely to add a bug to the main code. The current implementation recover's the abandoned connection based on an inactivity timeout. So it has to track the last time the connection was used. This more tightly couples it to DBCP. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
What happens is that the broken app ends up sucking up resources for each concurrent request being made to it which is waiting for the db connection timeout. Usually this is set to 5-10 seconds. This can suck up alot of resources. Memory, threads, etc. Web server with limited request/thread count will hung if app leaks connections and workarounds will not help, it will hung later, but it can be a solution for people who want to blame pool and ignore problems in application. It moves crap from application and makes it reusable component, is not it ? I see no problems if people want to produce crap at home, but I see no place for Observers in DBCP. Regards, Glenn - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
/** * Get a db connection from the pool. * * If removeAbandoned=true, recovers db connections which * have been idle removeAbandonedTimeout. * * @return Object jdbc Connection */ As I remember we have decided to log stack trace, but not to break pool. Is this code released as commons component ? - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 2:56 PM Subject: Re: [DBCP] AbandonedTrace - Connection Recovery John McNally wrote: [snip] On the implementation. I have not looked closely at the current implementation as it is not used by the pool that I added to dbcp and I was trying to start it as a simple implementation of the latest specification. But it would seem an implementation of this should just maintain a reference to Connection objects that it hands out and then after the allowed time period, it should call Connection.close(). The current jdbc specification states that a Connection object should not be usable after Connection.close() is called and the jdbc2pool implementation does not allow the Connection object to be used after close is called. Note that implementation is not perfect in that it needs to use wrapper implementations of Statement and ResultSet. But the idea is that once Connection.close() is called it should be safe for the pool to use the PooledConnection, which represents the physical connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls Connection.close() needs to be that coupled to the rest of the pool code and a simple event/listener model is not likely to add a bug to the main code. The current implementation recover's the abandoned connection based on an inactivity timeout. So it has to track the last time the connection was used. This more tightly couples it to DBCP. Regards, Glenn - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Juozas Baliuka wrote: /** * Get a db connection from the pool. * * If removeAbandoned=true, recovers db connections which * have been idle removeAbandonedTimeout. * * @return Object jdbc Connection */ As I remember we have decided to log stack trace, but not to break pool. There has been alot of discussion but no consensus has been reached yet nor has there been a vote. Is this code released as commons component ? Yes, the ability to recover abandoned connections was in the DBCP 1.0 release. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Using a WeakHashMap might be a good solution. Connections are guaranteed to be closed when they are garbage collected so if a client doesn't return a connection and loses all pointers to it, the pool would lose its reference to it and the Connection would get gc'd. This is *much* better than grabbing a connection away from the client application that may still be using it. Using a weak reference for pooled connections which are in use is a good idea and I am all for it. The only problem is that there is no guarantee when the weak referenced db connection pool object will be GC'd. That is highly dependent upon how the JVM implements GC. There is no guarantee that this would prevent abandoned connections from causing the pool to be exhausted. That's a valid point but unlikely to happen in a highly loaded server JVM that's creating and destroying many objects. I think it's sufficient to say that the pool won't hold onto connections that apps have lost but it's up to the apps not to lose them in the first place. David What would happen to the connection when it gets closed by garbage collection though? Since it's a pooled connection, calling close() tries to return it to the pool but the pool lost its reference to the connection when the client didn't return it. How would the pool ensure the connection originated from the pool? I'm sure that can be worked through. David In those circumstances garbage collection would free resources. I would think that their use is sensible so long as the pool can handle their garbage collection and get another one (though that may have the knock on effect of causing the getting of the connection to be synchronized to the client request - not a huge big deal in most cases but in a well managed resource environment such weak references would be unnecessary. for an explanation see: http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakReference.html Matt ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - 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] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - 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]
RE: [DBCP] AbandonedTrace - Connection Recovery
the weak reference should be to the true connection object itself or (making far easier to manage code) the finalize method on the class 'holding' the actual connection (this is not necessarily the ConnectionWrapper that manages putting it back in the pool - indeed it would be a good idea not to be) defers to the real connection and removes it from the pool. Not guaranteed to work because connection starvation can happen way before garbage collection can kick in with sufficient force to touch weak refrences. the generational stuff probably doesn't care about them for speed... Matt -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 15:48 To: Jakarta Commons Developers List Subject: RE: [DBCP] AbandonedTrace - Connection Recovery --- Hope, Matthew [EMAIL PROTECTED] wrote: -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 13:52 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Hope, Matthew wrote: I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). Using GC to log or recover an abandoned connection won't work because the connection is a member of the pool and will never be eligible for GC. Glenn I feel you may have missed my comment above to the effect that the pool is using a weakly referenced map. Using a WeakHashMap might be a good solution. Connections are guaranteed to be closed when they are garbage collected so if a client doesn't return a connection and loses all pointers to it, the pool would lose its reference to it and the Connection would get gc'd. This is *much* better than grabbing a connection away from the client application that may still be using it. What would happen to the connection when it gets closed by garbage collection though? Since it's a pooled connection, calling close() tries to return it to the pool but the pool lost its reference to the connection when the client didn't return it. How would the pool ensure the connection originated from the pool? David In those circumstances garbage collection would free resources. I would think that their use is sensible so long as the pool can handle their garbage collection and get another one (though that may have the knock on effect of causing the getting of the connection to be synchronized to the client request - not a huge big deal in most cases but in a well managed resource environment such weak references would be unnecessary. for an explanation see: http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakRefe rence.html Matt ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - 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] ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
The current implementation recover's the abandoned connection based on an inactivity timeout. So it has to track the last time the connection was used. This more tightly couples it to DBCP. That sounds like a better implementation as it is unlikely to timeout long running transactions. But implementing an Observer pattern in the Connection, Statement, ResultSet implementations would still allow such an implementation, right? john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I get the impression that some of you believe connection cleanup is difficult. It really is trivial to properly dispose of connections in a finally block. It is not always trivial. Yes, you can have some high level try/finally block to clean up resources, but you must make sure the code in the finally block has access to a Connection reference. Obviously, in the simple case where the Connection can be borrowed and returned in the same method, it is trivial. Not every case is that easy. It's even easier to find problems if you've properly layered the app so the database calls are all in one place. How do you do that when your application makes use of other components written by other teams/companies that have different policies. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Using a weak reference for pooled connections which are in use is a good idea and I am all for it. The only problem is that there is no guarantee when the weak referenced db connection pool object will be GC'd. That is highly dependent upon how the JVM implements GC. There is no guarantee that this would prevent abandoned connections from causing the pool to be exhausted. I had a case like this just a week ago, where an object that should have been closed when its use was done, because it was maintaining internally an open Connection. The bug never presented itself in our dev environments because the memory was low enough that gc was closing the object. Thankfully the test environments are more similar to production and the increased memory on those boxes caught the oversight. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
- Original Message - From: John McNally [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 8:54 PM Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I get the impression that some of you believe connection cleanup is difficult. It really is trivial to properly dispose of connections in a finally block. It is not always trivial. Yes, you can have some high level try/finally block to clean up resources, but you must make sure the code in the finally block has access to a Connection reference. ThreadLocal is used for this stuff. Obviously, in the simple case where the Connection can be borrowed and returned in the same method, it is trivial. Not every case is that easy. It's even easier to find problems if you've properly layered the app so the database calls are all in one place. How do you do that when your application makes use of other components written by other teams/companies that have different policies. Do not use broken code for production, but it must be possible to solve without broken pool. john mcnally - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Do not use broken code for production, but it must be possible to solve without broken pool. What utopia do you live in? I think it would be a close approximation to say that every piece of software in production use in the world today has bugs. And it is not a broken pool that allows the admin to set an idle timeout for connections anymore than it is a broken db that allows the same thing. You can keep calling it broken or crap, but your opinion does not matter much to me, have you contributed any code to dbcp, do you use it? I certainly hope not in production because its broken according to you. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Yes, my applications have a lot of bugs too, but I am not ignoring it and I am not going to break commons code to hide my problems . - Original Message - From: John McNally [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 10:54 PM Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Do not use broken code for production, but it must be possible to solve without broken pool. What utopia do you live in? I think it would be a close approximation to say that every piece of software in production use in the world today has bugs. And it is not a broken pool that allows the admin to set an idle timeout for connections anymore than it is a broken db that allows the same thing. You can keep calling it broken or crap, but your opinion does not matter much to me, have you contributed any code to dbcp, do you use it? I certainly hope not in production because its broken according to you. john mcnally - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Please do not misunderstand me, it is not a recomendation, it will not help too, but you can test this workaround at home: 1. before to return from getConnection pool sets currentThread for connection. 2. if !connection.getOwner().isAlive(), it safe to reuse connection. It must be safe to return the same connection for the same thread for the most of use cases too. It can help to hide problem and to crashe later, but it is not *common* way to solve problems . - Original Message - From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 4:16 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 13:52 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Hope, Matthew wrote: I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). Using GC to log or recover an abandoned connection won't work because the connection is a member of the pool and will never be eligible for GC. Glenn I feel you may have missed my comment above to the effect that the pool is using a weakly referenced map. In those circumstances garbage collection would free resources. I would think that their use is sensible so long as the pool can handle their garbage collection and get another one (though that may have the knock on effect of causing the getting of the connection to be synchronized to the client request - not a huge big deal in most cases but in a well managed resource environment such weak references would be unnecessary. for an explanation see: http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakReference.html Matt ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Please do not misunderstand me, it is not a recomendation, it will not help too, but you can test this workaround at home: 1. before to return from getConnection pool sets currentThread for connection. 2. if !connection.getOwner().isAlive(), it safe to reuse connection. It must be safe to return the same connection for the same thread for the most of use cases too. It can help to hide problem and to crashe later, but it is not *common* way to solve problems . - Original Message - From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 4:16 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 13:52 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Hope, Matthew wrote: I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). Using GC to log or recover an abandoned connection won't work because the connection is a member of the pool and will never be eligible for GC. Glenn I feel you may have missed my comment above to the effect that the pool is using a weakly referenced map. In those circumstances garbage collection would free resources. I would think that their use is sensible so long as the pool can handle their garbage collection and get another one (though that may have the knock on effect of causing the getting of the connection to be synchronized to the client request - not a huge big deal in most cases but in a well managed resource environment such weak references would be unnecessary. for an explanation see: http://java.sun.com/j2se/1.4.1/docs/api/java/lang/ref/WeakReference.html Matt ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - 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]
RE: [DBCP] AbandonedTrace - Connection Recovery
Serge, 1. Remove existing abandoned recovery attempt code. 2. Log when connections are abandoned and do not add them back into the pool. 3. Optionally log stack trace of where abandoned connection was first grabbed. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. I agree with your proposal, although I don't think I have a vote here. wrt point 4 I would suggest you consider allowing users to attach a listener/listeners to the pool and propogate the following events: ConnectionBorrowed - allow users to add a handler to test and possibly replace connections as they leave the pool ConnectionReturned - allow users to add a handler to test and discard (reallyClose()) connections returning to the pool ConnectionUnallocatedIdleTimeReached - allow users to add a handler to test and reallyClose() or replace connections idle in the pool beyond a confiigured idle timeout. ConnectionAllocatedIdleTimeReached - allow users to add a handler to reclaim connections allocated but idle beyond a configured idle timeout. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - 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]
RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas, I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. It is easy for you to say this, but the fact remains that a number of people are quite vocal in their support for it, it is wrong for us to ignore the needs of _all_ users, particularly if we are talking about removing functionality which already exists and is in use. Therefore there we have four options: 1/ We vote and the winning proposal is implemented leaving everyone else dissatisfied 2/ We retain the status quo 3/ Someone makes a change without the general consent of the group 4/ We reach a compromise. 1 is the Apache way. 2 is ignoring the issue. 3 is unacceptable and would cause trouble. 4 is surely the most reasonable course of action to take. Now I know you favour dropping support, others don't. What would you say if we retained it? What would they say if we dropped it? Alternatively Serge's proposal is a proposal for compromise, I was attempting to provide some support for the proposal by detailing one possible way in which a compromise can be accomodated, allowing both sets of users to have DBCP behave in the way they favour without breaking it for the others. If you believe my suggestions are garbage I suggest you help the process by suggesting an alternative compromise as it looks likely that only a compromise will be generally acceptable. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). this kind of thing almost certainly indicates a failure of application code or the library - both are things that are worth knowing about (my moneys on the app :¬). I fully agree with no attempt to 'recover' any sort of connection but it would assist debugging of legacy apps and other people's code if you could spot where the connection came from... Of course you could just take the view that p6spy does what you need and provide a pointer in that direction, commiters choice really... Matt -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 22 July 2003 13:16 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - 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] ** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
- Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:19 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery Juozas, I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. It is easy for you to say this, but the fact remains that a number of people are quite vocal in their support for it, it is wrong for us to ignore the needs of _all_ users, particularly if we are talking about removing functionality which already exists and is in use. Therefore there we have four options: 1/ We vote and the winning proposal is implemented leaving everyone else dissatisfied 2/ We retain the status quo 3/ Someone makes a change without the general consent of the group 4/ We reach a compromise. 1 is the Apache way. 2 is ignoring the issue. 3 is unacceptable and would cause trouble. 4 is surely the most reasonable course of action to take. Now I know you favour dropping support, others don't. What would you say if we retained it? I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . What would they say if we dropped it? Alternatively Serge's proposal is a proposal for compromise, I was attempting to provide some support for the proposal by detailing one possible way in which a compromise can be accomodated, allowing both sets of users to have DBCP behave in the way they favour without breaking it for the others. If you believe my suggestions are garbage I suggest you help the process by suggesting an alternative compromise as it looks likely that only a compromise will be generally acceptable. 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Danny Angus wrote: Serge et al, Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate. Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs. I don't have a vote in DBCP... Using the Observer pattern seems a fine approach, especially since the functionality was Voted on some time ago. Further, it sounds like you have tried to take others concerns into account, and discussed the issue. My 2 cents, It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings. 4. Provide some kind of extensible connection object that could allow someone to add their own (possibly included but optional) way to recover abandoned connections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rob Leland
RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas, I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . I think it is sad that you would rather leave than suggest any alternative. It highlights my point though, why should we expect those in favour of its retention to remain involved if we drop this when you won't remain involved if it is not dropped? Surely we should at least _try_ to accomodate both points of view? Or are also against even helping to find a compromise that would satify your requirements? I can see no technical reason why this should not be done, perhaps you can? If so why don't you help us by explaining why a compromise can never be acceptable to you. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
--- Danny Angus [EMAIL PROTECTED] wrote: Juozas, I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . I think it is sad that you would rather leave than suggest any alternative. It highlights my point though, why should we expect those in favour of its retention to remain involved if we drop this when you won't remain involved if it is not dropped? Surely we should at least _try_ to accomodate both points of view? Or are also against even helping to find a compromise that would satify your requirements? I can see no technical reason why this should not be done, perhaps you can? If so why don't you help us by explaining why a compromise can never be acceptable to you. IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. David d. - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. I'm not sure what you mean... supporting abandoned code will not fix code, and having Jakarta code fix (and encourage better design and keep people from writing their own bad implementations to common problems) are all great precedents. There is _no_ abandoned code approach that will fix code. Waiting for a finalizer to return a database collection will never result in an application behaving well. The issue is having more control over what happens in this situation, such as preventing a rarely called piece of code from failing quickly (will fail slowly, ideally allowing you tolerate it until fix in an upcoming release). I mean, c'mon, some apache developers are so full of themselves, I think they would welcome the opportunity to correct others code. :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
- Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:18 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery Juozas, I think I will leave commons and I will spend more my time on SF with forked code, if this kind of vote can win at apache. My input is not a very big, but I will lose any energy to work for crap . I think it is sad that you would rather leave than suggest any alternative. It highlights my point though, why should we expect those in favour of its retention to remain involved if we drop this when you won't remain involved if it is not dropped? Surely we should at least _try_ to accomodate both points of view? Or are also against even helping to find a compromise that would satify your requirements? I can see no technical reason why this should not be done, perhaps you can? If so why don't you help us by explaining why a compromise can never be acceptable to you. I believe application must work with any kind of pool implementation and not to depend on wokarounds in pool. This kind of wokaround breaks contract and portability, but can not solve resource management problem. I do not think it is good idea to experiment on stable component and I think a new subproject is the best compromise in this case. Resource manager it is not a traditional pool of database connections. The idea is very simple: 1. close is a programming error in managed code. 2. Resource manager is backed by any pool implementation. It is very trivial to implement and to port/fix any legacy code. 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
--- Serge Knystautas [EMAIL PROTECTED] wrote: David Graham wrote: IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. I'm not sure what you mean... supporting abandoned code will not fix code, and having Jakarta code fix (and encourage better design and keep people from writing their own bad implementations to common problems) are all great precedents. There is _no_ abandoned code approach that will fix code. Waiting for a finalizer to return a database collection will never result in an application behaving well. The issue is having more control over what happens in this situation, such as preventing a rarely called piece of code from failing quickly (will fail slowly, ideally allowing you tolerate it until fix in an upcoming release). Code should fail quickly to help debugging. If an app is worried about a resource leak, it could write a plugin to DBCP that knows what to do. DBCP has no way of knowing what the app should do in the event of a resource leak. This really isn't a coding issue; it's a policy and management issue. If you have apps that are leaking connections, give each app its own DataSource so it doesn't affect other applications. This is clearly outside of DBCP's scope. David I mean, c'mon, some apache developers are so full of themselves, I think they would welcome the opportunity to correct others code. :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [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]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 22 Jul 2003, Juozas Baliuka wrote: Date: Tue, 22 Jul 2003 14:15:53 +0200 From: Juozas Baliuka [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. The observer pattern is by no means useless. How many people have you seen ask for a way to accumulate statistics on the use of their pool? Event listeners are a very practical mechansim for anyone who wants to support this. It's also consistent with JavaBean event and listener patterns that are visible in a very large number of Java APIs. +1 for supporting events and listeners. -1 for including standard listener implementations in DBCP that attempt to do abandoned connection recovery (that's an exercise that can be left to the user). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 22 Jul 2003, Craig R. McClanahan wrote: On Tue, 22 Jul 2003, Juozas Baliuka wrote: Date: Tue, 22 Jul 2003 14:15:53 +0200 From: Juozas Baliuka [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. The observer pattern is by no means useless. How many people have you seen ask for a way to accumulate statistics on the use of their pool? Event listeners are a very practical mechansim for anyone who wants to support this. It's also consistent with JavaBean event and listener patterns that are visible in a very large number of Java APIs. +1 for supporting events and listeners. -1 for including standard listener implementations in DBCP that attempt to do abandoned connection recovery (that's an exercise that can be left to the user). Could a standard listener implementation be something contributed and placed in dbcp under contrib/? Just an idea. Adam K. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: --- Serge Knystautas [EMAIL PROTECTED] wrote: David Graham wrote: IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set. I'm not sure what you mean... supporting abandoned code will not fix code, and having Jakarta code fix (and encourage better design and keep people from writing their own bad implementations to common problems) are all great precedents. There is _no_ abandoned code approach that will fix code. Waiting for a finalizer to return a database collection will never result in an application behaving well. The issue is having more control over what happens in this situation, such as preventing a rarely called piece of code from failing quickly (will fail slowly, ideally allowing you tolerate it until fix in an upcoming release). Code should fail quickly to help debugging. If an app is worried about a resource leak, it could write a plugin to DBCP that knows what to do. DBCP has no way of knowing what the app should do in the event of a resource leak. This really isn't a coding issue; it's a policy and management issue. If you have apps that are leaking connections, give each app its own DataSource so it doesn't affect other applications. This is clearly outside of DBCP's scope. I agree that this is an education/policy issue. But sometimes you need a stop gap solution to keep something running while the customer fixes the problem. I would like to see this stop gap solution included with the DBCP release. Along with quality docs on how to properly use a db connection pool and a big disclaimer that the recovery of abandoned connections should only be used as a stop gap in an emergency until the customer has time to fix their code. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC onnection.html +1 to implement this interface, but I do not think it can help for broken applications. - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:38 PM Subject: Re: [DBCP] AbandonedTrace - Connection Recovery On Tue, 22 Jul 2003, Juozas Baliuka wrote: Date: Tue, 22 Jul 2003 14:15:53 +0200 From: Juozas Baliuka [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [DBCP] AbandonedTrace - Connection Recovery I do not think it is good idea to maintain any kind of public API for abandoned connections, It is garbage, If application or server is not broken, it doe's not need workarounds. Workarounds can not help for broken applications any way, it is a useless stuff and it infects code with Observers. As I understand it, people want to move problems from crappy applications to commons and to blame jakarta, but I think it is better to use the rigth way solve problems and a lot of solotions was proposed on this list too. The observer pattern is by no means useless. How many people have you seen ask for a way to accumulate statistics on the use of their pool? Event listeners are a very practical mechansim for anyone who wants to support this. It's also consistent with JavaBean event and listener patterns that are visible in a very large number of Java APIs. +1 for supporting events and listeners. -1 for including standard listener implementations in DBCP that attempt to do abandoned connection recovery (that's an exercise that can be left to the user). Craig - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
I agree that this is an education/policy issue. But sometimes you need a stop gap solution to keep something running while the customer fixes the problem. I would like to see this stop gap solution included with the DBCP release. Along with quality docs on how to properly use a db connection pool and a big disclaimer that the recovery of abandoned connections should only be used as a stop gap in an emergency until the customer has time to fix their code. Try to implement yourself and I am sure the time to fix a problem will mean forever and crappers will blame you then server or app will crache. Do you want to blame apache for this code ? This problem redirection will not help, but if you want, you can maintain this crap yourself, but do not try to redirect this problem to apache please. Regards, Glenn - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 2003-07-22 at 10:15, Juozas Baliuka wrote: http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC onnection.html +1 to implement this interface, but I do not think it can help for broken applications. That is an interface to be implemented by a jdbc driver vendor there is no reason for dbcp to implement it. dbcp.cpdsadapter provides a simple wrapper implementation for old jdbc 1.0 driver implementation. But it is not something a connection pool would normally need to code, it represents a physical connection to the db. john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
On Tue, 2003-07-22 at 10:28, Juozas Baliuka wrote: I agree that this is an education/policy issue. But sometimes you need a stop gap solution to keep something running while the customer fixes the problem. I would like to see this stop gap solution included with the DBCP release. Along with quality docs on how to properly use a db connection pool and a big disclaimer that the recovery of abandoned connections should only be used as a stop gap in an emergency until the customer has time to fix their code. Try to implement yourself and I am sure the time to fix a problem will mean forever and crappers will blame you then server or app will crache. Do you want to blame apache for this code ? This problem redirection will not help, but if you want, you can maintain this crap yourself, but do not try to redirect this problem to apache please. This attitude is not very helpful. I don't see how dbcp supplying the ability to configure a connection pool to reclaim connections is that big of an issue. It adds code complexity, but if the implementation is modified so that it is not central to the rest of the code and the critical bug entered against the current implementation is solved, we should allow it as part of the release. I was for the removal of this code, assuming the contributor had abandoned it and it had bugs no one else wanted to fix. But it is a perfectly valid feature and the original developer is stating he is willing to rewrite it. Is it not possible for many databases to configure an idle timeout? I'm pretty sure this kind of ability is to handle the same sort of badly written client code. Does mysql get blamed if a poorly written application loses a connection because it leaked it and did not close it, but mysql reclaims it. How about if the db admin sets the timeout too low and some normal running process ends up corrupting the data because it held a connection too long. I don't think so; it is important that the configuration options are set appropriately for the apps that will be using the database/connection pool. We are not taking on any responsibility for someone's crappy code by such a feature. Consider that you are using dbcp as your connection pool and your code is error-free. You are awaiting a feature from a partner/subcontractor. The feature runs some reporting queries on an interval of 15 minutes and it is known that the queries generally take about a minute. It turns out the partners code is flawed and you are going to lose money, if you have to wait for a fix and start integration testing again after a delay. There might be all sorts of other remedies to this, but being able to configure the pool to recover the connections in the pool being used by the partners code would be optimal, imo. You can then just continue, or worse case immediately start over on, your integration testing. Features related to connection management are appropriate in a connection pool. Is it inappropriate for tomcat to allow an admin to configure a security policy, since well written code will not do anything it shouldn't? On the implementation. I have not looked closely at the current implementation as it is not used by the pool that I added to dbcp and I was trying to start it as a simple implementation of the latest specification. But it would seem an implementation of this should just maintain a reference to Connection objects that it hands out and then after the allowed time period, it should call Connection.close(). The current jdbc specification states that a Connection object should not be usable after Connection.close() is called and the jdbc2pool implementation does not allow the Connection object to be used after close is called. Note that implementation is not perfect in that it needs to use wrapper implementations of Statement and ResultSet. But the idea is that once Connection.close() is called it should be safe for the pool to use the PooledConnection, which represents the physical connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls Connection.close() needs to be that coupled to the rest of the pool code and a simple event/listener model is not likely to add a bug to the main code. Why is this such a contentious issue? john mcnally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
-Original Message- From: John McNally [mailto:[EMAIL PROTECTED] Why is this such a contentious issue? FWIW, because some users have business experience, and some do not. Those who do recognize that business *runs* on stopgap solutions. The fewer of those stopgap solutions you have to write, the better, IMHO. Count me among those who would like to see this ability, but as a separate plugin, or a subclass, etc. Cheers, Laird - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] AbandonedTrace - Connection Recovery
--- Laird J. Nelson [EMAIL PROTECTED] wrote: -Original Message- From: John McNally [mailto:[EMAIL PROTECTED] Why is this such a contentious issue? FWIW, because some users have business experience, and some do not. Those who do recognize that business *runs* on stopgap solutions. The fewer of those stopgap solutions you have to write, the better, IMHO. Your implication that those of us arguing against this feature do not have real business experience has not gone unnoticed. This is especially interesting considering one of the most respected developers around here, Craig McClanahan, is arguing against this feature as well. You presume to know too much about your fellow developer's experiences. I have seen enough bad JDBC code to know that a feature like this is popular. Why should I bother writing good database code if the pool will just cleanup after me? Some developers have chosen to argue from the emotional/purist point of view. I choose to argue from the practical side. A connection pool has absolutely no way of knowing when a connection has been abandoned. If you configure the pool to reclaim connections after x minutes and a new app comes along that needs it for x+1 minutes you will have a *very* confusing bug caused by DBCP. This is absolutely not a DBCP code issue; it is a management issue. Applications that leak resources should have their own separate connection pool. When they run out of connections, only that app will break and won't affect any other applications on the server. It will be much easier to debug the leak in the isolated app because DBCP won't hide it from you and you won't have to search any other apps. So, there is no need for this feature in DBCP if the above process is followed. This makes everyone's life simpler :-). David Count me among those who would like to see this ability, but as a separate plugin, or a subclass, etc. Cheers, Laird - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: This is absolutely not a DBCP code issue; it is a management issue. Applications that leak resources should have their own separate connection pool. When they run out of connections, only that app will break and won't affect any other applications on the server. It will be much easier to debug the leak in the isolated app because DBCP won't hide it from you and you won't have to search any other apps. So, there is no need for this feature in DBCP if the above process is followed. This makes everyone's life simpler :-). I think business might be replaced with many situations in the real world. I dream of well run projects. Developers who follow processes that make everyone's life easier. Ah, that would be nice. Is there such a land? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I like innovations, but try to implement and test it at home please. I am sure there are not so many situations in the real world need this feature. It takes a few minutes to find connection leak and to fix it in any applications, doe's not it ? David Graham wrote: This is absolutely not a DBCP code issue; it is a management issue. Applications that leak resources should have their own separate connection pool. When they run out of connections, only that app will break and won't affect any other applications on the server. It will be much easier to debug the leak in the isolated app because DBCP won't hide it from you and you won't have to search any other apps. So, there is no need for this feature in DBCP if the above process is followed. This makes everyone's life simpler :-). I think business might be replaced with many situations in the real world. I dream of well run projects. Developers who follow processes that make everyone's life easier. Ah, that would be nice. Is there such a land? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [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]
Re: [DBCP] AbandonedTrace - Connection Recovery
Juozas Baliuka wrote: I like innovations, but try to implement and test it at home please. I am sure there are not so many situations in the real world need this feature. It takes a few minutes to find connection leak and to fix it in any applications, doe's not it ? It does not. I have 2 new clients in the past 3 months (one medium, and one huge highly publicized screwed-up government project) that both have connection leak issues that they have been working at for a long time. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
This attitude is not very helpful. I don't see how dbcp supplying the ability to configure a connection pool to reclaim connections is that big of an issue. Have you tried to solve problems this way ? Is it tested solution and can be used for high quality software ? Try to implement and test anti patterns at home first. It adds code complexity, but if the implementation is modified so that it is not central to the rest of the code and the critical bug entered against the current implementation is solved, we should allow it as part of the release. I was for the removal of this code, assuming the contributor had abandoned it and it had bugs no one else wanted to fix. But it is a perfectly valid feature and the original developer is stating he is willing to rewrite it. Is it not possible for many databases to configure an idle timeout? I'm pretty sure this kind of ability is to handle the same sort of badly written client code. Does mysql get blamed if a poorly written application loses a connection because it leaked it and did not close it, but mysql reclaims it. It is not a feature too, It breaks transactions, I do not believe it supports autoreconnect if transactions are enabled. How about if the db admin sets the timeout too low and some normal running process ends up corrupting the data because it held a connection too long. I don't think so; it is important that the configuration options are set appropriately for the apps that will be using the database/connection pool. We are not taking on any responsibility for someone's crappy code by such a feature. Consider that you are using dbcp as your connection pool and your code is error-free. You are awaiting a feature from a partner/subcontractor. The feature runs some reporting queries on an interval of 15 minutes and it is known that the queries generally take about a minute. It turns out the partners code is flawed and you are going to lose money, if you have to wait for a fix and start integration testing again after a delay. There might be all sorts of other remedies to this, but being able to configure the pool to recover the connections in the pool being used by the partners code would be optimal, imo. You can then just continue, or worse case immediately start over on, your integration testing. Features related to connection management are appropriate in a connection pool. Is it inappropriate for tomcat to allow an admin to configure a security policy, since well written code will not do anything it shouldn't? On the implementation. I have not looked closely at the current implementation as it is not used by the pool that I added to dbcp and I was trying to start it as a simple implementation of the latest specification. But it would seem an implementation of this should just maintain a reference to Connection objects that it hands out and then after the allowed time period, it should call Connection.close(). The current jdbc specification states that a Connection object should not be usable after Connection.close() is called and the jdbc2pool implementation does not allow the Connection object to be used after close is called. Note that implementation is not perfect in that it needs to use wrapper implementations of Statement and ResultSet. But the idea is that once Connection.close() is called it should be safe for the pool to use the PooledConnection, which represents the physical connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls Connection.close() needs to be that coupled to the rest of the pool code and a simple event/listener model is not likely to add a bug to the main code. Why is this such a contentious issue? john mcnally - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: I fess up, I am the guilty party who added the ability to trace abandoned connections and recover them. ;-) Sorry to jump in late on this. I have been busy with other things. The motivation behind this was to allow a servlet container to continue operating normally even if you have customers who either wrote crappy code themselves or hired consultants who wrote crappy code. This helps improve servlet container availability in these situations and logs information which can help track down the problem. The only solution when crappy code causes problems with exhausting the connection pool is to stop and restart the container. I don't know about you, but I don't like getting paged in the evening or on weekends due to someone elses crappy code. I can appreciate the arguments for a cleaner DBCP implementation. And refactoring its design to clean it up can be a good thing. But the ability to track and close abandoned db connections is vital from my perspective. I strongly urge that the ability to do this be retained in DBCP. If the refactored core of DBCP allows this by subclasssing it, great. But those sub classes to support this should be released with DBCP. I strongly disagree. You getting paged due to someone's poor coding abilities is outside the scope of DBCP. There are much more effective ways of preventing pages than by developing a library that covers up coding mistakes so that they persist indefinitely. So, what are these more effective ways to prevent pages? The current dbcp code for detecting abandoned connections doesn't cover up the problem, it logs that there is a problem and correctly identifies the code responsible. Yes, in a perfect world all code deployed would be thoroughly tested and bug free. But I don't think that will happen in my lifeftime. The servlet containers db connection pool is the best place to detect and correct this problem. Whether the code to do this is in the DBCP core or in sub classes doesn't matter to me. Just as long as the ability to do this comes with the DBCP release. Server availability is a very high priority for me. DBCP should be designed in a way that allows behaviors to be plugged in which includes grabbing abandoned connections. This should absolutely not be shipped with DBCP because there is no reasonable way for it to know what is abandoned in every situation. Great, we agree that the core of DBCP should be designed so that this feature could be implemented in a subclass. :-) You may feel that there is no reasonable way to know when a connection is abandoned. Fine, you don't have to use it, work on the code, document it, support it, etc. That is not a good reason IMHO to prevent those who feel it is a very important feature from including a sub class which supports this with the DBCP release. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Forget it please. Try to solve it at home, fix it or remove crap from production . I do not think commons commiters want or need to support crap. All of us have a lot of work at home too and there are a lot of good code to support. - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, July 21, 2003 4:51 PM Subject: Re: [DBCP] AbandonedTrace - Connection Recovery David Graham wrote: I fess up, I am the guilty party who added the ability to trace abandoned connections and recover them. ;-) Sorry to jump in late on this. I have been busy with other things. The motivation behind this was to allow a servlet container to continue operating normally even if you have customers who either wrote crappy code themselves or hired consultants who wrote crappy code. This helps improve servlet container availability in these situations and logs information which can help track down the problem. The only solution when crappy code causes problems with exhausting the connection pool is to stop and restart the container. I don't know about you, but I don't like getting paged in the evening or on weekends due to someone elses crappy code. I can appreciate the arguments for a cleaner DBCP implementation. And refactoring its design to clean it up can be a good thing. But the ability to track and close abandoned db connections is vital from my perspective. I strongly urge that the ability to do this be retained in DBCP. If the refactored core of DBCP allows this by subclasssing it, great. But those sub classes to support this should be released with DBCP. I strongly disagree. You getting paged due to someone's poor coding abilities is outside the scope of DBCP. There are much more effective ways of preventing pages than by developing a library that covers up coding mistakes so that they persist indefinitely. So, what are these more effective ways to prevent pages? The current dbcp code for detecting abandoned connections doesn't cover up the problem, it logs that there is a problem and correctly identifies the code responsible. Yes, in a perfect world all code deployed would be thoroughly tested and bug free. But I don't think that will happen in my lifeftime. The servlet containers db connection pool is the best place to detect and correct this problem. Whether the code to do this is in the DBCP core or in sub classes doesn't matter to me. Just as long as the ability to do this comes with the DBCP release. Server availability is a very high priority for me. DBCP should be designed in a way that allows behaviors to be plugged in which includes grabbing abandoned connections. This should absolutely not be shipped with DBCP because there is no reasonable way for it to know what is abandoned in every situation. Great, we agree that the core of DBCP should be designed so that this feature could be implemented in a subclass. :-) You may feel that there is no reasonable way to know when a connection is abandoned. Fine, you don't have to use it, work on the code, document it, support it, etc. That is not a good reason IMHO to prevent those who feel it is a very important feature from including a sub class which supports this with the DBCP release. Regards, Glenn - 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]
Re: [DBCP] AbandonedTrace - Connection Recovery
I strongly disagree. You getting paged due to someone's poor coding abilities is outside the scope of DBCP. There are much more effective ways of preventing pages than by developing a library that covers up coding mistakes so that they persist indefinitely. So, what are these more effective ways to prevent pages? Not deploying code with resource leaks, training developers on proper resource cleanup, calling developers responsible for the resource leak in the middle of the night to help you fix the problem, etc. The current dbcp code for detecting abandoned connections doesn't cover up the problem, it logs that there is a problem and correctly identifies the code responsible. Yes, in a perfect world all code deployed would be thoroughly tested and bug free. But I don't think that will happen in my lifeftime. The servlet containers db connection pool is the best place to detect and correct this problem. The individual apps causing the problems is the best place to correct the problem. Whether the code to do this is in the DBCP core or in sub classes doesn't matter to me. Just as long as the ability to do this comes with the DBCP release. Server availability is a very high priority for me. Then don't deploy code that leaks resources. DBCP should be designed in a way that allows behaviors to be plugged in which includes grabbing abandoned connections. This should absolutely not be shipped with DBCP because there is no reasonable way for it to know what is abandoned in every situation. Great, we agree that the core of DBCP should be designed so that this feature could be implemented in a subclass. :-) Not necessarily in a subclass. That's one of the biggest flaws in the current implementation. You may feel that there is no reasonable way to know when a connection is abandoned. Fine, you don't have to use it, work on the code, document it, support it, etc. That is not a good reason IMHO to prevent those who feel it is a very important feature from including a sub class which supports this with the DBCP release. The fact that DBCP cannot reliably determine whether a connection has been abandoned is a very good reason to not include that feature. Only the apps know how they will be using connections and consequently, only the apps have enough information to determine when a connection is abandoned. This discussion is old. We already decided not to include this feature with DBCP but compromised on a design that allows this behavior to be plugged in and perhaps log possible leaks. David Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
So, what are these more effective ways to prevent pages? Not deploying code with resource leaks, training developers on proper resource cleanup, calling developers responsible for the resource leak in the middle of the night to help you fix the problem, etc. I forgot one: If apps are leaking database connections, just setup a different DataSource for each app. That way they will only affect themselves and not bring down other apps. The database will eventually close connections on its own so the only real issue is the leak in the apps. You could go even further and only give suspect applications a very limited number of connections in the pool (ie. 2) until they prove they're not leaking connections. This is much more of a policy/management problem than one that can be solved in DBCP. David __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
David Graham wrote: That is not a good reason IMHO to prevent those who feel it is a very important feature from including a sub class which supports this with the DBCP release. The fact that DBCP cannot reliably determine whether a connection has been abandoned is a very good reason to not include that feature. Only the apps know how they will be using connections and consequently, only the apps have enough information to determine when a connection is abandoned. This discussion is old. We already decided not to include this feature with DBCP but compromised on a design that allows this behavior to be plugged in and perhaps log possible leaks. Yes the discussion is old, and I apologized for jumping in late. This isn't a new discussion. The support for tracking abandoned connections wasn't snuck in. This was discussed on this list and consensus reached to add support for tracking abandoned connections to DBCP 1.0 in Feb 2002. From my reading of all the messages in the current thread there are a number of people in both camps. There are valid arguments on each side. But I don't see where a consensus was reached. There were some proposals made and some good ideas tossed around. But there definitely wasn't a VOTE on a proposed set of changes for DBCP 2.0. I did see votes for three new commons committers who have volunteered to work on DBCP 2.0. Thats great. I for one would like to see a proposal made and voted on for DBCP 2.0. I also think that when there is a design issue being discussed where consensus can not be reached there should be a VOTE. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
--- Juozas Baliuka [EMAIL PROTECTED] wrote: Forget it please. Try to solve it at home, fix it or remove crap from production . I do not think commons commiters want or need to support crap. I am not a commons committer, but as a user, I would humbly suggest that server products may need to support crap running inside them. Phil All of us have a lot of work at home too and there are a lot of good code to support. - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Monday, July 21, 2003 4:51 PM Subject: Re: [DBCP] AbandonedTrace - Connection Recovery David Graham wrote: I fess up, I am the guilty party who added the ability to trace abandoned connections and recover them. ;-) Sorry to jump in late on this. I have been busy with other things. The motivation behind this was to allow a servlet container to continue operating normally even if you have customers who either wrote crappy code themselves or hired consultants who wrote crappy code. This helps improve servlet container availability in these situations and logs information which can help track down the problem. The only solution when crappy code causes problems with exhausting the connection pool is to stop and restart the container. I don't know about you, but I don't like getting paged in the evening or on weekends due to someone elses crappy code. I can appreciate the arguments for a cleaner DBCP implementation. And refactoring its design to clean it up can be a good thing. But the ability to track and close abandoned db connections is vital from my perspective. I strongly urge that the ability to do this be retained in DBCP. If the refactored core of DBCP allows this by subclasssing it, great. But those sub classes to support this should be released with DBCP. I strongly disagree. You getting paged due to someone's poor coding abilities is outside the scope of DBCP. There are much more effective ways of preventing pages than by developing a library that covers up coding mistakes so that they persist indefinitely. So, what are these more effective ways to prevent pages? The current dbcp code for detecting abandoned connections doesn't cover up the problem, it logs that there is a problem and correctly identifies the code responsible. Yes, in a perfect world all code deployed would be thoroughly tested and bug free. But I don't think that will happen in my lifeftime. The servlet containers db connection pool is the best place to detect and correct this problem. Whether the code to do this is in the DBCP core or in sub classes doesn't matter to me. Just as long as the ability to do this comes with the DBCP release. Server availability is a very high priority for me. DBCP should be designed in a way that allows behaviors to be plugged in which includes grabbing abandoned connections. This should absolutely not be shipped with DBCP because there is no reasonable way for it to know what is abandoned in every situation. Great, we agree that the core of DBCP should be designed so that this feature could be implemented in a subclass. :-) You may feel that there is no reasonable way to know when a connection is abandoned. Fine, you don't have to use it, work on the code, document it, support it, etc. That is not a good reason IMHO to prevent those who feel it is a very important feature from including a sub class which supports this with the DBCP release. Regards, Glenn - 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!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
Noel J. Bergman wrote: It appears clear that there are two camps, each with fairly strong views. Personally, I believe that both camps can be accomodated in a way that should satisfy both. DBCP should focus on core pooling behavior related to connections and prepared statements, and leave policy issues to specialized subclasses. If DBCP is clean, without any reclaiming of connections and properly setup to be subclassed, including subclassing a delegating connection, then whomever needs a specialized connection pool that reclaims connections based upon some policy can do so. DelegatingConnection, and the rest of the core objects should be pure and focused only on the necessary behavior to implement connection pooling. DBCP should focus on what has to happen when a connection is requested or returned. Behavior, not policy, should be the watch word. There is enough behavior to deal with related to connection pooling, including ensuring the proper state of pooled connections. Some of the AbandonedTrace behavior is still necessary to implement the JDBC specification. Connections still need to track outstanding statements and results sets, which are closed by Connection.close(). However, the abandoned semantic is not in the specification. It is perfectly permissible to leave a ResultSet or Statement open, and expect the connection to close it. Nor is it necessary for DBCP to track leaks, regardless of whether or not it is implementing recovery. Both of that behavior can be implemented by specialized subclasses. DBCP may wish to provide abstract classes that facilitate specialization. I fess up, I am the guilty party who added the ability to trace abandoned connections and recover them. ;-) Sorry to jump in late on this. I have been busy with other things. The motivation behind this was to allow a servlet container to continue operating normally even if you have customers who either wrote crappy code themselves or hired consultants who wrote crappy code. This helps improve servlet container availability in these situations and logs information which can help track down the problem. The only solution when crappy code causes problems with exhausting the connection pool is to stop and restart the container. I don't know about you, but I don't like getting paged in the evening or on weekends due to someone elses crappy code. I can appreciate the arguments for a cleaner DBCP implementation. And refactoring its design to clean it up can be a good thing. But the ability to track and close abandoned db connections is vital from my perspective. I strongly urge that the ability to do this be retained in DBCP. If the refactored core of DBCP allows this by subclasssing it, great. But those sub classes to support this should be released with DBCP. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] AbandonedTrace - Connection Recovery
I fess up, I am the guilty party who added the ability to trace abandoned connections and recover them. ;-) Sorry to jump in late on this. I have been busy with other things. The motivation behind this was to allow a servlet container to continue operating normally even if you have customers who either wrote crappy code themselves or hired consultants who wrote crappy code. This helps improve servlet container availability in these situations and logs information which can help track down the problem. The only solution when crappy code causes problems with exhausting the connection pool is to stop and restart the container. I don't know about you, but I don't like getting paged in the evening or on weekends due to someone elses crappy code. I can appreciate the arguments for a cleaner DBCP implementation. And refactoring its design to clean it up can be a good thing. But the ability to track and close abandoned db connections is vital from my perspective. I strongly urge that the ability to do this be retained in DBCP. If the refactored core of DBCP allows this by subclasssing it, great. But those sub classes to support this should be released with DBCP. I strongly disagree. You getting paged due to someone's poor coding abilities is outside the scope of DBCP. There are much more effective ways of preventing pages than by developing a library that covers up coding mistakes so that they persist indefinitely. DBCP should be designed in a way that allows behaviors to be plugged in which includes grabbing abandoned connections. This should absolutely not be shipped with DBCP because there is no reasonable way for it to know what is abandoned in every situation. David Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
