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]
