--- 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]
