commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <stei...@yahoo.com>
Subject Re: [DBCP] AbandonedTrace - Connection Recovery
Date Mon, 21 Jul 2003 18:53:50 GMT
--- Juozas Baliuka <baliuka@mwm.lt> 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" <glenn@mail.more.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message