commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [DBCP] AbandonedTrace - Connection Recovery
Date Mon, 21 Jul 2003 16:27:38 GMT

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


Mime
View raw message