You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Glenn Nielsen <gl...@mail.more.net> on 2003/07/21 05:06:48 UTC
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Phil Steitz <st...@yahoo.com>.
--- Juozas Baliuka <ba...@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" <gl...@mail.more.net>
> To: "Jakarta Commons Developers List" <co...@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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@mwm.lt>.
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" <gl...@mail.more.net>
To: "Jakarta Commons Developers List" <co...@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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by John McNally <jm...@collab.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@centras.lt>.
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" <cr...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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 <ba...@mwm.lt>
> > Reply-To: Jakarta Commons Developers List
<co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > 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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by adam kramer <ad...@monkey.org>.
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 <ba...@mwm.lt>
> > Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 22 Jul 2003, Juozas Baliuka wrote:
> Date: Tue, 22 Jul 2003 14:15:53 +0200
> From: Juozas Baliuka <ba...@mwm.lt>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@mwm.lt>.
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@centras.lt>.
>
> 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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@mwm.lt>.
/**
* 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" <gl...@mail.more.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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: 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
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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?
Let me please take advantage of this moment of sanity to point out that
there have been over 100 messages on this topic, and we're still were we
were back on June 29th, when David Graham said "I am open to designing DBCP
in such a way that allows people to plugin the behaviors they need including
reclaming connections (the Strategy pattern may be useful here)."
If anyone can point to any real new ground, I've missed it in the noise.
There has been more spinning on this discussion than in the Tour de France.
Are we agreed that the base functionality will facilitate pluggable
behavior? If so, let's move on, shall we? There are other issues worth
discussing, such as the state of logging, and the unfortunate use of
System.out.println ... <self clothing=nomex state=laughing/>
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by John McNally <jm...@collab.net>.
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@mwm.lt>.
> 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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@centras.lt>.
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" <jm...@collab.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by John McNally <jm...@collab.net>.
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@centras.lt>.
----- Original Message -----
From: "John McNally" <jm...@collab.net>
To: <co...@jakarta.apache.org>
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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by John McNally <jm...@collab.net>.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
> I am really getting tired of the 'purists' in this discussion telling
> the 'realists', "Just fix your code".
>
> That is not the issue at all. Those who are advocating to retain this
> feature are doing so from an application server admin perspective.
> When I have had to deal with this problem as the application server
> admin there are many times when I don't even have access to the code.
> Its the customers code.
>
> And yes, my organization does provide our customers with guidelines
> with Do's and Dont's when writing web applications which includes a
> discussion of db connection pooling and how to make sure the
> db connection is closed properly.
Do you also have a policy for what the consequences are for apps that leak
resources? I still see this as outside DBCP's scope. Adding kludges to
DBCP is really not the best way to solve this problem.
David
>
> Regards,
>
> Glenn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
David Graham wrote:
> --- Glenn Nielsen <gl...@mail.more.net> wrote:
>
>>David Graham wrote:
>>
>>>--- "Laird J. Nelson" <la...@comcast.net> wrote:
>>>
>>>
>>>>>-----Original Message-----
>>>>>From: John McNally [mailto:jmcnally@collab.net]
>>>>>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.
>
>
> Right, I meant that it won't affect the database operations of other apps.
> The bottom line is that DBCP shouldn't try to fix broken code. There are
> many ways an app can break, connection leaks being one of them. It's not
> our job to fix all the broken code in the world. There needs to be a
> clearly defined separation of concerns between DBCP and client code.
> Resource cleanup is clearly in the domain of the client.
>
> 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's even easier to find problems if you've properly
> layered the app so the database calls are all in one place.
>
I am really getting tired of the 'purists' in this discussion telling
the 'realists', "Just fix your code".
That is not the issue at all. Those who are advocating to retain this
feature are doing so from an application server admin perspective.
When I have had to deal with this problem as the application server
admin there are many times when I don't even have access to the code.
Its the customers code.
And yes, my organization does provide our customers with guidelines
with Do's and Dont's when writing web applications which includes a
discussion of db connection pooling and how to make sure the
db connection is closed properly.
Regards,
Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
--- Glenn Nielsen <gl...@mail.more.net> wrote:
> David Graham wrote:
> > --- "Laird J. Nelson" <la...@comcast.net> wrote:
> >
> >>>-----Original Message-----
> >>>From: John McNally [mailto:jmcnally@collab.net]
> >>>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.
Right, I meant that it won't affect the database operations of other apps.
The bottom line is that DBCP shouldn't try to fix broken code. There are
many ways an app can break, connection leaks being one of them. It's not
our job to fix all the broken code in the world. There needs to be a
clearly defined separation of concerns between DBCP and client code.
Resource cleanup is clearly in the domain of the client.
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's even easier to find problems if you've properly
layered the app so the database calls are all in one place.
David
>
> Regards,
>
> Glenn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
David Graham wrote:
> --- "Laird J. Nelson" <la...@comcast.net> wrote:
>
>>>-----Original Message-----
>>>From: John McNally [mailto:jmcnally@collab.net]
>>>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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@mwm.lt>.
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. sergek@lokitech.com
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Serge Knystautas <se...@lokitech.com>.
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. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@centras.lt>.
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. sergek@lokitech.com
>
>
> ---------------------------------------------------------------------
> 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Serge Knystautas <se...@lokitech.com>.
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. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
--- "Laird J. Nelson" <la...@comcast.net> wrote:
> > -----Original Message-----
> > From: John McNally [mailto:jmcnally@collab.net]
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by "Laird J. Nelson" <la...@comcast.net>.
> -----Original Message-----
> From: John McNally [mailto:jmcnally@collab.net]
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by John McNally <jm...@collab.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@centras.lt>.
> 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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
David Graham wrote:
> --- Serge Knystautas <se...@lokitech.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
--- Serge Knystautas <se...@lokitech.com> 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. sergek@lokitech.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Serge Knystautas <se...@lokitech.com>.
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. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
--- Danny Angus <da...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by Danny Angus <da...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@mwm.lt>.
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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: 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
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by Danny Angus <da...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Juozas Baliuka <ba...@mwm.lt>.
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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Rob Leland <rl...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
--
Rob Leland
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by Danny Angus <da...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [DBCP] AbandonedTrace - Connection Recovery
Posted by Danny Angus <da...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Serge Knystautas <se...@lokitech.com>.
Glenn Nielsen wrote:
> 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.
Proposal - Adjustment to DBCP's connection recovery
(there are 4 points of what is my single proposal)
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.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
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 glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
> > 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: 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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by David Graham <gr...@yahoo.com>.
> 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: 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