You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Anton Tagunov <at...@mail.cnt.ru> on 2003/06/28 02:32:45 UTC
Re[2]: DBCP status?
Hi, all!
JMcN> I am the primary developer of the jdbc2pool and cpdsadapter packages.
JMcN> I do not see any reason to merge the code into one package with the rest
JMcN> of dbcp. They seem packaged appropriately to me. The main thing that
JMcN> needs to be done here is to rename the "jdbc2" in the names to something
JMcN> else. I don't know what is a better name, but we should not release
JMcN> with "jdbc" in the class or package names.
Have looked at jdbc2pool a couple of weeks ago (we have probably both
participated in the bugzilla discussion, didn't we? :)
To me jdbc2pool looked not ready for a release.
On the other hand cpdsadapter and the rest of dbcp
looked like after a bit of work (in which Serge Knystautas
will probably participate :-) they will be quite ready for
a release.
Do you agree?
(That there may be a release soon, but without
jdbc2 part, not to hold the progress ?)
JMcN> If anyone wants to become an active developer on dbcp, they are welcome
Not right now, but the subject is certainly hot :-)
DG> As for the "deluge" of commons-dev mail, it has been suggested
DG> that DBCP move to db-commons which would alleviate that problem.
Is there much chance this will happen?
SK> Anybody know what Tomcat is using at this point?
Indeed would be interesting to see that :-)
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by Juozas Baliuka <ba...@mwm.lt>.
It is possible to detect "abandoned" connection with Thread.isAlive() (if
thread pool is not used or maxConnections >= maxThreads),
but it is not a good way for performance ( iterate "owners" and chech
"isAlive" )
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, June 30, 2003 12:47 PM
Subject: RE: DBCP status?
> I think we've had this discussion before.
>
> But I'll weigh in with my 2c again because I still feel strongly about
it..
>
> Craig says:
>
> > I do not believe there is any fundamentally sound algorithm that a
> > connection pool can use to detect when a connection has truly been
> > "abandoned" and is thereby suitable for recovery. And, grabbing back
> > connections that are actually in use is *much* worse than leaking them,
> > because you immediately break an application that is currenty executing,
> > in ways that are very unpredictable, hard to reproduce, and basically
> > impossible to recover from.
>
>
> I agree.
>
> IMO It is fundamentally better to let leaks result in the problems
associated with leaks (run out of connections) than to replace a set of
known, quantifiable and understood symptoms with Mystery and Confusion.
>
> d.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: DBCP status?
Posted by Danny Angus <da...@apache.org>.
I think we've had this discussion before.
But I'll weigh in with my 2c again because I still feel strongly about it..
Craig says:
> I do not believe there is any fundamentally sound algorithm that a
> connection pool can use to detect when a connection has truly been
> "abandoned" and is thereby suitable for recovery. And, grabbing back
> connections that are actually in use is *much* worse than leaking them,
> because you immediately break an application that is currenty executing,
> in ways that are very unpredictable, hard to reproduce, and basically
> impossible to recover from.
I agree.
IMO It is fundamentally better to let leaks result in the problems associated with leaks (run out of connections) than to replace a set of known, quantifiable and understood symptoms with Mystery and Confusion.
d.
Re: DBCP status?
Posted by Juozas Baliuka <ba...@centras.lt>.
>
> That is most likely why people want DBCP to recover connections but again
> this is beyond the scope of DBCP. Fixing the applications to manage their
> resources appropriately is the solution in this case.
>
+1
I prefer to remove all resource management workarounds from DBCP and use
"fail-fast" way.
It must help to solve problems not to hide them.
> 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
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 2003.06.21
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by Juozas Baliuka <ba...@mwm.lt>.
> ResultSet rs;
> try {
> con = magicGetConnection();
> //stuff
> } catch(...) {
> } finally {
> try {if (rs!=null){ rs.close(); rs=null; } } catch(Throwable ignore){}
> try {if (ps!=null){ ps.close(); ps=null; } } catch(Throwable ignore){}
> try {if (ps!=null){ con.close(); con=null; } } catch(Throwable
ignore){}
> }
>
> In the above code - I try to use the good practice of try-catch-finally.
My
> code works great in the testing environment (of course it should fail in
> stress testing in cases it can be done).
There are a lot of good ways to manage resources, but I think it is out of
DBCP scope.
Workarounds in pool can not help in this case too ("try {if (ps!=null){
con.close(); con=null; } } catch(Throwable ignore){}")
"maxConnections = 1" can better help to find this kind of problems.
Let handle this stuff for JDBC frontends. Is is very easy to implement JDBC
resource management.
I use JDBC API this way at this time:
void method( String arg1, .... ){
JdbcUtils.executeSQL( "SELECT .....", new Object[]{ arg1 , ...},
new Callback(){
public void handle( ResultSet rs ){
.... handle results ....
}
}
);
}
There are a lot of opensource frameworks like IBATIS, Voruta,
SpringFramework, ... DbUtils in sandbox is a minimalist tool for JDBC API
too. It is very easy to learn and use this kind of frameworks, just add
links to JDBC frontends and it will solve database progamming problems
better.
I prefer pools without workarounds, it can help to find and fix problem. Do
not to hide problems, it solves nothing.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- Tim Funk <fu...@joedog.org> wrote:
> David Graham wrote:
> > 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). However, DBCP should never provide that
> > functionality out of the box because it implies that Jakarta supports
> poor
> > programming practices.
> >
>
> +1 for allowing people to plugin their own "kludge" to reclaim
> connections.
> In a perfect world we (ok, me) wouldn't need the reclaiming connection
> code.
> But I still (in fact 3 weeks ago) fall victim to the following cut and
> paste
> typos, for example:
>
> Connection con;
> PreparedStatement ps;
> ResultSet rs;
> try {
> con = magicGetConnection();
> //stuff
> } catch(...) {
> } finally {
> try {if (rs!=null){ rs.close(); rs=null; } } catch(Throwable
> ignore){}
> try {if (ps!=null){ ps.close(); ps=null; } } catch(Throwable
> ignore){}
> try {if (ps!=null){ con.close(); con=null; } } catch(Throwable
> ignore){}
> }
Well the first mistake here is catching Throwable (a bad idea) and then
ignoring it (a really bad idea). The second mistake is not factoring this
error prone code into a more maintainable form. Adding a couple of
methods like:
closeConnection(Connection conn) {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
// log e here
}
}
}
would have prevented your problem in the first place.
David
>
> In the above code - I try to use the good practice of try-catch-finally.
> My
> code works great in the testing environment (of course it should fail in
>
> stress testing in cases it can be done). The peer review goes great (or
> gets
> ommitted for some places which don't have that luxury) and the peer
> reviewer
> also overlooks the leaking connection. Time for production - within
> hours -
> the site starts acting strange but only intermittently. The reclamation
> of
> connections keeps the site running and the logging we get allows us to
> say "O
> crap!" and fix the problem quickly.
>
> Some of try to use great programming practices but we are mere mortals.
> I am
> not in favor of haphazardly yanking connections. But in some
> environments,
> yanking the connection away from the application may not be that bad of
> a
> thing.
>
>
> -Tim
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by Steve Raeburn <st...@ninsky.com>.
My $0.02 is that the cure (reclaiming connections) is worse that the disease
(leaking connections through programmer error).
Better intermittent problems due to faulty code (which though hard to find
is possible to correct) than intermittent problems when your code is 100%
correct. How hard would *that* be to fix!?
Steve
> -----Original Message-----
> From: Tim Funk [mailto:funkman@joedog.org]
> Sent: June 29, 2003 6:18 PM
> To: Jakarta Commons Developers List
> Subject: Re: DBCP status?
>
>
> David Graham wrote:
> > 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). However, DBCP should never provide that
> > functionality out of the box because it implies that Jakarta
> supports poor
> > programming practices.
> >
>
> +1 for allowing people to plugin their own "kludge" to reclaim
> connections.
> In a perfect world we (ok, me) wouldn't need the reclaiming
> connection code.
> But I still (in fact 3 weeks ago) fall victim to the following
> cut and paste
> typos, for example:
>
> Connection con;
> PreparedStatement ps;
> ResultSet rs;
> try {
> con = magicGetConnection();
> //stuff
> } catch(...) {
> } finally {
> try {if (rs!=null){ rs.close(); rs=null; } } catch(Throwable ignore){}
> try {if (ps!=null){ ps.close(); ps=null; } } catch(Throwable ignore){}
> try {if (ps!=null){ con.close(); con=null; } } catch(Throwable
> ignore){}
> }
>
> In the above code - I try to use the good practice of
> try-catch-finally. My
> code works great in the testing environment (of course it should fail in
> stress testing in cases it can be done). The peer review goes
> great (or gets
> ommitted for some places which don't have that luxury) and the
> peer reviewer
> also overlooks the leaking connection. Time for production -
> within hours -
> the site starts acting strange but only intermittently. The
> reclamation of
> connections keeps the site running and the logging we get allows
> us to say "O
> crap!" and fix the problem quickly.
>
> Some of try to use great programming practices but we are mere
> mortals. I am
> not in favor of haphazardly yanking connections. But in some
> environments,
> yanking the connection away from the application may not be that bad of a
> thing.
>
>
> -Tim
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by Tim Funk <fu...@joedog.org>.
David Graham wrote:
> 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). However, DBCP should never provide that
> functionality out of the box because it implies that Jakarta supports poor
> programming practices.
>
+1 for allowing people to plugin their own "kludge" to reclaim connections.
In a perfect world we (ok, me) wouldn't need the reclaiming connection code.
But I still (in fact 3 weeks ago) fall victim to the following cut and paste
typos, for example:
Connection con;
PreparedStatement ps;
ResultSet rs;
try {
con = magicGetConnection();
//stuff
} catch(...) {
} finally {
try {if (rs!=null){ rs.close(); rs=null; } } catch(Throwable ignore){}
try {if (ps!=null){ ps.close(); ps=null; } } catch(Throwable ignore){}
try {if (ps!=null){ con.close(); con=null; } } catch(Throwable ignore){}
}
In the above code - I try to use the good practice of try-catch-finally. My
code works great in the testing environment (of course it should fail in
stress testing in cases it can be done). The peer review goes great (or gets
ommitted for some places which don't have that luxury) and the peer reviewer
also overlooks the leaking connection. Time for production - within hours -
the site starts acting strange but only intermittently. The reclamation of
connections keeps the site running and the logging we get allows us to say "O
crap!" and fix the problem quickly.
Some of try to use great programming practices but we are mere mortals. I am
not in favor of haphazardly yanking connections. But in some environments,
yanking the connection away from the application may not be that bad of a
thing.
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re[2]: DBCP status?
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hi, All!
1) A side-note
It would be really more easy if this discussion was
held somewhere on db-commons, really :-)
2)
PS> The EAI or network infrastructure, for example, behind one of the
PS> apps could cause it to grind to a halt, effectively orphaning any
PS> connections that it has open, depriving the other apps of these
PS> resources.
Hey, there's one more solution!
So far we have discussed two possible actions if a connection
has not been returned to a pool too long:
a) just log it as an error and do nothing
b) forcibly bring it back to the pool
But we can have c) here:
c) log this as an error and no longer consider the connection
as part of the pool!
That is, if
* the pool is configured to have 10 connections max
* our "too long not returned" time out is configured to be 60 seconds
* all 10 connections have been taken out
* one of them has not been returned for over 60 seconds
We just "forget" about the "too long not returned" connection
and consider that our pool now has only 9 connections.
This allows us to create one new connection and give it
to the waiting clients.
If afterwards the offending connection is returned after all
there are two ways IMO to handle it
i) not put back to pull at all, just close it uncoditionally
ii) see how many connections we have in the pool, if we have
bellow 10, add it to the pool, if we have all 10 already,
close it as being excessive
This solution leaves the abandoned connections to be reclaimed
but the regular database timeout (8 hours for the standard
MySQL setup) which is not that bad.
This of course won't work too well if the database limits
the number of connections available to, say 10, by the license,
but I propose the following criteria:
***
The situation when the pool is applied shouldn't be worse
then it would be if we had no pool.
***
Of course if maxActive is non-zero this criteria is not obeyed
anyway, so my solution best applies if maxActive is 0.
What to do if maxActive is positive I'm at a loss
- Anton
P.S. The following note by David Graham probably makes
this behavior unnecessary, still I wanted to propose it.
DG> If your environment has the above characteristics, each
DG> application would have its own separate connection pool
DG> so a failure in one app would not affect another.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> David Graham wrote:
> > --- "Noel J. Bergman" <no...@devtech.com> wrote:
> >
> >>David,
> >>
> >>I hope that you have not gotten the impression that I am arguing with
> >>you.
> >
> >
> > Nope, I was just stating my point of view :-). I will continue to
> argue
> > against recovering connections until someone can make a solid case
> that
> > persuades me otherwise.
>
> Here is an attempt at making the case for some form or "connection
> recycling" or "aggressive connection management". I have tried to
> address your main points, which I agree are the central ones. Please
> take this for what it is -- just another viewpoint based on what may be
> incomplete or incorrect understanding of what dbcp is trying to do.
>
> > Here are the main problems:
> >
> > 1. Pools should not grab resources back from applications.
>
> Unless there is a contract that says that connections not used for more
> than a configurable "Orphan timeout" can be reclaimed. Are you ruling
> out this possibility? See for example, the configuration parameter
> called "Orphan tiemout" defined here:
>
http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/ae/udat_was4poolset.html.
>
> Client apps are free to set the timeout to be effectively infinite if
> they want and connections enlisted in transactions are not reclaimed.
> Note that even if the pool doesn't do it, the engine eventually will
> timeout unused connections anyway.
Of course if you define the pool contract that way then it is allowable.
The separation of concerns I'm defining says that DBCP is responsible for
maintaining a connection pool and clients are responsible for borrowing
and returning connections. Putting connection reclamation into DBCP is an
undue burden on it when the logical place for that responsibility is with
the client.
>
> > 2. Even if pools were allowed to do that, there is no algorithm for
> doing
> > so in a reasonable manner.
>
> I agree that there is certainly no algorithm for divining when a
> connection has been abandoned by an application. If the pool has
> knowledge of when connections are being used, however, it can certainly
> enforce idle timeouts.
If there is no sound algorithm, how can DBCP enforce idle timeouts? The
most DBCP should do is log a possible connection leak because it lacks
enough information to make a judgement about leaked connections. Only the
client application has that information. This is also a reason why DBCP
should not ship with a pluggable "connection reclamation" behavior.
>
> > 3. There seem to be no reasons other than laziness or fear for
> wanting
> > the pool to reclaim connections.
>
> Fear is a good thing for resource managers (or any other server
> component).
>
> What it comes down to here, IMHO, is what dbcp wants to be. If it wants
>
> to be a lightweight component used by single applications in a
> controlled environment, then it does not have to be robust against
> misbehaving clients, clients that abandon connections, or clients that
> hold idle connections too long. If the aim is something like Tomcat +
> dbcp = <insert your favorite commercial container> - EJBs, then it needs
>
> to be more robust.
DBCP can be robust without reclaming connections.
>
> >
> > 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). However, DBCP should never provide that
> > functionality out of the box because it implies that Jakarta supports
> poor
> > programming practices.
>
> I disagree with the assertion that making the pool robust against
> abandoned connections supports "poor programming practices". First,
> just because an API can be misused, that does not mean that the design
> of the API promotes or encourages the misuse. Second, in a shared
> environment, there may be situations in which connections get
> effectively abandoned without "poor programming practices" -- at least
> not in the database access code. The EAI or network infrastructure, for
> example, behind one of the apps could cause it to grind to a halt,
> effectively orphaning any connections that it has open, depriving the
> other apps of these resources. Here again, it depends on what the goal
> of dbcp is. If deployment in large scale apps in a shared environment
> is a goal, then it needs to aggressively manage resources.
I disagree. If your environment has the above characteristics, each
application would have its own separate connection pool so a failure in
one app would not affect another.
David
>
> Obviously, all of this is just my own point of view and since I have
> contributed nothing to dbcp, it should not carry much weight. If others
>
> feel the same way, however, and there is interest in either developing a
>
> pluggable strategy to support configurable "connection recycling" or
> other connection management extensions, I would be willing to help out.
>
> Phil
>
> >
> > I believe debate is a great way of coming to a solution. Thanks for
> > participating in this one.
> >
> > David
> >
> >
> >>I asked you what you felt had led to the previous problems. There are
> >>clearly differences of opinions amongst the people asking for and
> >>rejecting
> >>the idea of recovering connections, and I wanted to hear what people
> >>thought.
> >>
> >> --- Noel
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> >
>
>
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by Phil Steitz <ph...@steitz.com>.
David Graham wrote:
> --- "Noel J. Bergman" <no...@devtech.com> wrote:
>
>>David,
>>
>>I hope that you have not gotten the impression that I am arguing with
>>you.
>
>
> Nope, I was just stating my point of view :-). I will continue to argue
> against recovering connections until someone can make a solid case that
> persuades me otherwise.
Here is an attempt at making the case for some form or "connection
recycling" or "aggressive connection management". I have tried to
address your main points, which I agree are the central ones. Please
take this for what it is -- just another viewpoint based on what may be
incomplete or incorrect understanding of what dbcp is trying to do.
> Here are the main problems:
>
> 1. Pools should not grab resources back from applications.
Unless there is a contract that says that connections not used for more
than a configurable "Orphan timeout" can be reclaimed. Are you ruling
out this possibility? See for example, the configuration parameter
called "Orphan tiemout" defined here:
http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/ae/udat_was4poolset.html.
Client apps are free to set the timeout to be effectively infinite if
they want and connections enlisted in transactions are not reclaimed.
Note that even if the pool doesn't do it, the engine eventually will
timeout unused connections anyway.
> 2. Even if pools were allowed to do that, there is no algorithm for doing
> so in a reasonable manner.
I agree that there is certainly no algorithm for divining when a
connection has been abandoned by an application. If the pool has
knowledge of when connections are being used, however, it can certainly
enforce idle timeouts.
> 3. There seem to be no reasons other than laziness or fear for wanting
> the pool to reclaim connections.
Fear is a good thing for resource managers (or any other server component).
What it comes down to here, IMHO, is what dbcp wants to be. If it wants
to be a lightweight component used by single applications in a
controlled environment, then it does not have to be robust against
misbehaving clients, clients that abandon connections, or clients that
hold idle connections too long. If the aim is something like Tomcat +
dbcp = <insert your favorite commercial container> - EJBs, then it needs
to be more robust.
>
> 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). However, DBCP should never provide that
> functionality out of the box because it implies that Jakarta supports poor
> programming practices.
I disagree with the assertion that making the pool robust against
abandoned connections supports "poor programming practices". First,
just because an API can be misused, that does not mean that the design
of the API promotes or encourages the misuse. Second, in a shared
environment, there may be situations in which connections get
effectively abandoned without "poor programming practices" -- at least
not in the database access code. The EAI or network infrastructure, for
example, behind one of the apps could cause it to grind to a halt,
effectively orphaning any connections that it has open, depriving the
other apps of these resources. Here again, it depends on what the goal
of dbcp is. If deployment in large scale apps in a shared environment
is a goal, then it needs to aggressively manage resources.
Obviously, all of this is just my own point of view and since I have
contributed nothing to dbcp, it should not carry much weight. If others
feel the same way, however, and there is interest in either developing a
pluggable strategy to support configurable "connection recycling" or
other connection management extensions, I would be willing to help out.
Phil
>
> I believe debate is a great way of coming to a solution. Thanks for
> participating in this one.
>
> David
>
>
>>I asked you what you felt had led to the previous problems. There are
>>clearly differences of opinions amongst the people asking for and
>>rejecting
>>the idea of recovering connections, and I wanted to hear what people
>>thought.
>>
>> --- Noel
>>
>>
>>---------------------------------------------------------------------
>>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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- "Noel J. Bergman" <no...@devtech.com> wrote:
> David,
>
> I hope that you have not gotten the impression that I am arguing with
> you.
Nope, I was just stating my point of view :-). I will continue to argue
against recovering connections until someone can make a solid case that
persuades me otherwise. Here are the main problems:
1. Pools should not grab resources back from applications.
2. Even if pools were allowed to do that, there is no algorithm for doing
so in a reasonable manner.
3. There seem to be no reasons other than laziness or fear for wanting
the pool to reclaim connections.
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). However, DBCP should never provide that
functionality out of the box because it implies that Jakarta supports poor
programming practices.
I believe debate is a great way of coming to a solution. Thanks for
participating in this one.
David
> I asked you what you felt had led to the previous problems. There are
> clearly differences of opinions amongst the people asking for and
> rejecting
> the idea of recovering connections, and I wanted to hear what people
> thought.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by "Noel J. Bergman" <no...@devtech.com>.
David,
I hope that you have not gotten the impression that I am arguing with you.
I asked you what you felt had led to the previous problems. There are
clearly differences of opinions amongst the people asking for and rejecting
the idea of recovering connections, and I wanted to hear what people
thought.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- "Noel J. Bergman" <no...@devtech.com> wrote:
> > I do not believe there is any fundamentally sound algorithm that a
> > connection pool can use to detect when a connection has truly been
> > "abandoned" and is thereby suitable for recovery.
>
> If we did not have a pool, the server would eventually (a) run out of
> connections, possibly impacting other applications in the system and/or
> (b)
> timeout excessively old connections. Those timeouts are generally very
> long. The default in MySQL is 8 hours.
This configuration is well beyond the scope of DBCP.
>
> The question to ask is the purpose of a connection pool. If it is to
> improve performance, then it has a set of jobs. Changing the
> characteristics of the preceeding paragraph are not included in that set
> of
> jobs.
Performance improvement is the main reason to use pooling.
>
> Where people want a connection pool to recover abandoned connections,
> that
> usually points to either poor programming within a particular
> application,
> or sharing by multiple application components, one of which may have a
> problem. Essentially, they want to shorten the server timeout, so that
> other components can't deny service by losing track of connections.
>
> Do you concur with this analysis?
That is most likely why people want DBCP to recover connections but again
this is beyond the scope of DBCP. Fixing the applications to manage their
resources appropriately is the solution in this case.
David
>
> > It's really sad that people writing database driven software using a
> > connection pool don't seem to be aware of how trivially simple it is
> to
> > make sure that connection leaks do not happen to them, using a
> > try/catch/finally block to ensure that the release always happens.
>
> I agree. The code that I use is even more that what you posted, so much
> so
> that it led me to develop a functor-type approach for our internal use,
> where I provide the normative database operation(s) that we want
> performed,
> and the core library manages the rest.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I do not believe there is any fundamentally sound algorithm that a
> connection pool can use to detect when a connection has truly been
> "abandoned" and is thereby suitable for recovery.
If we did not have a pool, the server would eventually (a) run out of
connections, possibly impacting other applications in the system and/or (b)
timeout excessively old connections. Those timeouts are generally very
long. The default in MySQL is 8 hours.
The question to ask is the purpose of a connection pool. If it is to
improve performance, then it has a set of jobs. Changing the
characteristics of the preceeding paragraph are not included in that set of
jobs.
Where people want a connection pool to recover abandoned connections, that
usually points to either poor programming within a particular application,
or sharing by multiple application components, one of which may have a
problem. Essentially, they want to shorten the server timeout, so that
other components can't deny service by losing track of connections.
Do you concur with this analysis?
> It's really sad that people writing database driven software using a
> connection pool don't seem to be aware of how trivially simple it is to
> make sure that connection leaks do not happen to them, using a
> try/catch/finally block to ensure that the release always happens.
I agree. The code that I use is even more that what you posted, so much so
that it led me to develop a functor-type approach for our internal use,
where I provide the normative database operation(s) that we want performed,
and the core library manages the rest.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Sat, 28 Jun 2003, Noel J. Bergman wrote:
>
> > Date: Sat, 28 Jun 2003 14:34:05 -0400
> > From: Noel J. Bergman <no...@devtech.com>
> > Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> > dgraham@apache.org
> > Subject: RE: DBCP status?
> >
> > > > - Better support/debugging for forcing connections closed after
> being
> > > > open for "too long"
> >
> > > This is exactly what got DBCP into trouble in the past. I'm -1 on
> > > providing any ability in DBCP to close lost connections. DBCP
> should
> > > provide the ability to *log* when it detects a resource leak but the
> > > application is responsible for the health of the pool.
> >
> > I understand your view, but do you believe that there is no possible
> > solution? If it is just an implementation concern, I'd just as soon
> see
> > what solution someone comes up with. In your opinion, what are/were
> the
> > problems in handling "abandoned" connections in DBCP?
> >
>
> I agree with David (and others who think a pool trying to recover things
> is a bad idea).
>
> I do not believe there is any fundamentally sound algorithm that a
> connection pool can use to detect when a connection has truly been
> "abandoned" and is thereby suitable for recovery. And, grabbing back
> connections that are actually in use is *much* worse than leaking them,
> because you immediately break an application that is currenty executing,
> in ways that are very unpredictable, hard to reproduce, and basically
> impossible to recover from.
>
> It's really sad that people writing database driven software using a
> connection pool don't seem to be aware of how trivially simple it is to
> make sure that connection leaks do not happen to them, using a
> try/catch/finally block to ensure that the release always happens.
While the code below isn't difficult to understand, it is rather lengthy
which probably leads to developers not cleaning up connections properly.
I started the Mapper project in the commons-sandbox, in part, to deal with
the error prone nature of JDBC coding. It's not suitable for every use
case but I've found it invaluable in shortening my code and ensuring
resources are properly disposed.
David
>
> DataSource ds = ... reference to your pool ...;
> Connection conn = null;
> PreparedStatement stmt = null;
> ResultSet rs = null;
> try {
>
> // Allocate a connection from the pool
> conn = ds.getConnection();
>
> // Use it to perform some processing -- either directly
> stmt = conn.prepareStatement("SELECT ...");
> rs = stmt.executeQuery();
> while (rs.next()) {
> ... process this row ...
> }
> rs.close();
> rs = null;
> stmt.close();
> stms = null;
>
> // Or pass the allocated connection on to some other method
> doMyDatabaseTransaction(conn);
>
> // Keep doing transactions on this connection until you are done
>
> } finally {
>
> // Release allocated resources, no matter what exception was thrown
> if (rs != null) {
> try {
> rs.close();
> } catch (SQLException e) {
> ; // Or log it
> }
> rs = null;
> }
> if (stmt != null) {
> try {
> stms.close();
> } catch (SQLException e) {
> ; // Or log it
> }
> stmt = null;
> }
> if (conn != null) {
> try {
> conn.close(); // Returns connection to the pool
> } catch (SQLException e) {
> ; // Or log it
> }
> conn = null;
> }
> }
>
> > --- Noel
>
> Craig
__________________________________
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 status?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 28 Jun 2003, Noel J. Bergman wrote:
> Date: Sat, 28 Jun 2003 14:34:05 -0400
> From: Noel J. Bergman <no...@devtech.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> dgraham@apache.org
> Subject: RE: DBCP status?
>
> > > - Better support/debugging for forcing connections closed after being
> > > open for "too long"
>
> > This is exactly what got DBCP into trouble in the past. I'm -1 on
> > providing any ability in DBCP to close lost connections. DBCP should
> > provide the ability to *log* when it detects a resource leak but the
> > application is responsible for the health of the pool.
>
> I understand your view, but do you believe that there is no possible
> solution? If it is just an implementation concern, I'd just as soon see
> what solution someone comes up with. In your opinion, what are/were the
> problems in handling "abandoned" connections in DBCP?
>
I agree with David (and others who think a pool trying to recover things
is a bad idea).
I do not believe there is any fundamentally sound algorithm that a
connection pool can use to detect when a connection has truly been
"abandoned" and is thereby suitable for recovery. And, grabbing back
connections that are actually in use is *much* worse than leaking them,
because you immediately break an application that is currenty executing,
in ways that are very unpredictable, hard to reproduce, and basically
impossible to recover from.
It's really sad that people writing database driven software using a
connection pool don't seem to be aware of how trivially simple it is to
make sure that connection leaks do not happen to them, using a
try/catch/finally block to ensure that the release always happens.
DataSource ds = ... reference to your pool ...;
Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
// Allocate a connection from the pool
conn = ds.getConnection();
// Use it to perform some processing -- either directly
stmt = conn.prepareStatement("SELECT ...");
rs = stmt.executeQuery();
while (rs.next()) {
... process this row ...
}
rs.close();
rs = null;
stmt.close();
stms = null;
// Or pass the allocated connection on to some other method
doMyDatabaseTransaction(conn);
// Keep doing transactions on this connection until you are done
} finally {
// Release allocated resources, no matter what exception was thrown
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
; // Or log it
}
rs = null;
}
if (stmt != null) {
try {
stms.close();
} catch (SQLException e) {
; // Or log it
}
stmt = null;
}
if (conn != null) {
try {
conn.close(); // Returns connection to the pool
} catch (SQLException e) {
; // Or log it
}
conn = null;
}
}
> --- Noel
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- Rodney Waldhoff <rw...@apache.org> wrote:
> The code was buggy and added complexity both in and out of the
> AbandonedConnectionPool.
>
> Some would argue that recovering from programmer error is not an
> appropriate role for a component like DBCP, and for what it's worth, I
> think I'm probably one of those.
>
> That said, I think changing dbcp/pool to be more compositional and less
> extend-to-customize-oriented would be a good move all around, and should
> make it possible to add abandoned object recovery (or abandoned object
> logging, or a host of other things) as a decorator--which should make it
> orthogonal to the other implementations/concerns.
Recovering lost connections whether implemented with a class hierarchy or
composition is an extremely bad idea. If DBCP is designed to allow
pluggable behaviors in general and someone decides to implement connection
recovery for their application, that's their problem. We shouldn't be
promoting poor practices by supporting connection recovery directly from
DBCP.
David
>
> - Rod <http://radio.weblogs.com/0122027/>
>
> On Sat, 28 Jun 2003, Noel J. Bergman wrote:
>
> > > > - Better support/debugging for forcing connections closed after
> being
> > > > open for "too long"
> >
> > > This is exactly what got DBCP into trouble in the past. I'm -1 on
> > > providing any ability in DBCP to close lost connections. DBCP
> should
> > > provide the ability to *log* when it detects a resource leak but the
> > > application is responsible for the health of the pool.
> >
> > I understand your view, but do you believe that there is no possible
> > solution? If it is just an implementation concern, I'd just as soon
> see
> > what solution someone comes up with. In your opinion, what are/were
> the
> > problems in handling "abandoned" connections in DBCP?
> >
> > --- Noel
> >
> >
> > ---------------------------------------------------------------------
> > 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 status?
Posted by Rodney Waldhoff <rw...@apache.org>.
The code was buggy and added complexity both in and out of the
AbandonedConnectionPool.
Some would argue that recovering from programmer error is not an
appropriate role for a component like DBCP, and for what it's worth, I
think I'm probably one of those.
That said, I think changing dbcp/pool to be more compositional and less
extend-to-customize-oriented would be a good move all around, and should
make it possible to add abandoned object recovery (or abandoned object
logging, or a host of other things) as a decorator--which should make it
orthogonal to the other implementations/concerns.
- Rod <http://radio.weblogs.com/0122027/>
On Sat, 28 Jun 2003, Noel J. Bergman wrote:
> > > - Better support/debugging for forcing connections closed after being
> > > open for "too long"
>
> > This is exactly what got DBCP into trouble in the past. I'm -1 on
> > providing any ability in DBCP to close lost connections. DBCP should
> > provide the ability to *log* when it detects a resource leak but the
> > application is responsible for the health of the pool.
>
> I understand your view, but do you believe that there is no possible
> solution? If it is just an implementation concern, I'd just as soon see
> what solution someone comes up with. In your opinion, what are/were the
> problems in handling "abandoned" connections in DBCP?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by David Graham <gr...@yahoo.com>.
--- Tim Funk <fu...@joedog.org> wrote:
> That's all well and nice until a request fires a condition where it
> doesn't
> close the connection and takes down the server or makes all requests
> fail due
> to an exhausted pool. Which can only be fixed on the short term by a
> webserver restart. Which is what a sysadmin will due, report it in a log
> and
> the root cause doesn't get fixed.
If one of your apps can take down your whole server, nothing we could do
in DBCP will help you. Not closing connections is one of many bugs that
can occur in an application and the prevention of those bugs is not DBCP's
responsibility. The detection and notification of lost connections should
be DBCP's responsibility to speed debugging.
David
>
> I would be content to see it configurable to automagically close
> connections
> or just state a warning.
>
> For me this isn't an issue since I wrote my own pool for my employer,
> but I'd
> rather dump my code and use one with more mindshare like dbcp. If I do
> that -
> automagically "killing" connections will be essential.
>
> FWIW - in my pool code - I use a facade to mask the real dbms
> connection. If
> the too much time passes by - I close the real dbms connection(since the
>
> coder probably did lots of bad things) and set it to null so future
> attempts
> by the bad app immediately fails. In the context of a web request - this
> is
> acceptable for my situation. In hindsight - what I should do is throw a
> RuntimeException instead of having a NPE be thrown. The RuntimeException
>
> would have a "nice message" stating that the connection was closed
> because it
> was open too long. (I just thought of this 5 seconds ago, I haven't
> determined if its a good idea yet)
>
> I'll try to stay quiet now (and go back to lurking since I'm not really
> contributing to commons, I apologize to all if I sound like noise)
> Hopefully
> closer to the 4th quarter - I can help out.
>
> -Tim
>
> David Graham wrote:
>
> > The pool should keep track of how long a connection has been checked
> out
> > and log a message when it passes some configurable threshold but it
> should
> > never try to grab the connection back from the application.
> >
> > David
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by Tim Funk <fu...@joedog.org>.
That's all well and nice until a request fires a condition where it doesn't
close the connection and takes down the server or makes all requests fail due
to an exhausted pool. Which can only be fixed on the short term by a
webserver restart. Which is what a sysadmin will due, report it in a log and
the root cause doesn't get fixed.
I would be content to see it configurable to automagically close connections
or just state a warning.
For me this isn't an issue since I wrote my own pool for my employer, but I'd
rather dump my code and use one with more mindshare like dbcp. If I do that -
automagically "killing" connections will be essential.
FWIW - in my pool code - I use a facade to mask the real dbms connection. If
the too much time passes by - I close the real dbms connection(since the
coder probably did lots of bad things) and set it to null so future attempts
by the bad app immediately fails. In the context of a web request - this is
acceptable for my situation. In hindsight - what I should do is throw a
RuntimeException instead of having a NPE be thrown. The RuntimeException
would have a "nice message" stating that the connection was closed because it
was open too long. (I just thought of this 5 seconds ago, I haven't
determined if its a good idea yet)
I'll try to stay quiet now (and go back to lurking since I'm not really
contributing to commons, I apologize to all if I sound like noise) Hopefully
closer to the 4th quarter - I can help out.
-Tim
David Graham wrote:
> The pool should keep track of how long a connection has been checked out
> and log a message when it passes some configurable threshold but it should
> never try to grab the connection back from the application.
>
> David
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re[2]: DBCP status?
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Serge!
Serge Knystautas wrote:
SK> I agree trying to recover connections is bad. I've found it leads to
SK> problems that don't show up during a test phase become very confusing
SK> and challenging problems in production once under high-load.
SK> The approach I took was this....
SK> a) support an optional max-active time threshold, which means there is a
SK> time limit to how long a connection can be marked as in use.
SK> b) if this threshold is exceeded, you close the connection. The value
SK> of trying to return it to the pool is minimal, while the downside of
SK> returning a mid-transaction/statement connection to a pool is very bad
SK> and nearly impossible to track down.
Yes, the connection shouldn't be put back to pool.
Yes, we should log this as an error.
Yes, the Throwable from section c) will greately help.
If the pool is to provide any feedback statistics
probably we should report separately three values:
* # of active connections
* # of idle connections
* # of over-timed connections
Now, two questions of the year:
b1) to close this connection or not to close?
b2) if maxActive > 0 should this connection no longer be counted
as active for the purpose of enforcing the policies of
WHEN_EXHAUSTED_FAIL
WHEN_EXHAUSTED_BLOCK
?
I guess we have to choose from the following matrix of alternatives
b1 b2
1 1
0 0
0 1
Thoughts?
SK> c) support an optional debug step that will create a Throwable when
SK> getConnection is called. Then if the max-active threshold is hit, we
SK> can print the stack trace of where the aged connection was grabbed, and
SK> in development/testing, quickly resolve the errant connection.
This is a separate idea on its own and a very good one I think :-)
The message logging a connection that has been borrowed from the
pool too long will greatly benefit from this stack trace.
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by Juozas Baliuka <ba...@centras.lt>.
> b) suggested workaround?
There are a lot of good ways, but you can try this:
1. implement connection wrapper this way :
methods are delegated to pooled connection, but not "close", it throws
Exception.(trivial step)
2. remove all "close" application code (trivial step).
3. Implement resource manager. It can be "Filter", "Controler" or
"BaseAction" in web application, "BaseThread" in multithreaded application,
"main" method in single threaded aplication or some "Dispacher" for
messaging.
"3." is a very trivial too:
public class ConnectionManager implements Filter {
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
try {
Connection c = datasource.getConnection();
ManagetConnection managed = decorate(c);
request.setAttribute("myConnection",managed);
chain.doFilter(request, response);
}finally{
c.close();
}
}
You can store managed connection in request attribute, ThreadLocal or as
method parameter.
I use it in production ( ThreadLocal ) and this way is very good for me.
It takes a few minutes for refactoring some application and solve all
resource leak problems without workarounds in pools.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 2003.06.24
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: DBCP status?
Posted by Danny Angus <da...@apache.org>.
Serge,
> I *need* the pooler to close connections that have been borrowed from
> the pool and forgotten to be closed. Can you give a) reasons why not to
> close them because of an optional parameter and b) suggested workaround?
Why? I can think of a couple of reasons you might give, but I'm seriously not convinced that it is a legitimate thing for the pool to do.
Can you sell it to us?
> I think there's a relunctance (including mine) to create a dependency on
> commons-logging (or another logger), so I was thinking about a
> PoolListener service.
FWIW I authored a JDBC connection pool and file & URL cache library for work, my experience is this.. we started off with logging, it is vital to know exactly what the pools and caches think is going on while your library is under development.
However once we started putting stable product into other software we quickly discovered that logging is unnecessary, if anything is going on you use a debugger, if it is going well you don't want the kind of logs these things produce. We eventually added a listener API and found it to be much more satisfactory.
+1 to that idea.
There would be classes of events for:
> a) creating a connection
> b) grabbing a connection
> c) closing a connection
> d) a connection getting too old
I think that if in case d) your listener can intervene in the connection lifecycle then it is unnecessary to have DBCP frceably close connections.
d.
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 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 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 "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
Re: [DBCP] AbandonedTrace - Connection Recovery
Posted by Glenn Nielsen <gl...@mail.more.net>.
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 status?
Posted by David Graham <gr...@yahoo.com>.
--- "Noel J. Bergman" <no...@devtech.com> wrote:
> > > 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().
>
> > Agreed, but the way it was implemented was completely wrong. The
> behavior
> > should not have been in a superclass and forced unrelated classes to
> > subclass it.
>
> I actually had a sentence about that, but I removed it.
>
> > Let DBCP focus on it's core responsibilities and provide easy
> > hooks to allow logging, policy decisions, etc.
>
> What hooks do you see as necessary in the base class(es)?
Listener and Strategy architectures are really useful for implementing
hooks that don't require subclassing. I really think DBCP should use
commons-logging but if the majority believes otherwise, I'll make that
compromise. For other features we may be able to leverage the
notifications that commons-pool already sends out and translate them into
DBCP events.
I'd like to see the next release of DBCP squash the open bugs and then we
can remove the deprecated Abandoned* classes and start on some new ideas.
If they're significantly different than the current DBCP, we can increment
the major release number to 2.0 and break backwards compatibility to move
forward.
David
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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().
> Agreed, but the way it was implemented was completely wrong. The behavior
> should not have been in a superclass and forced unrelated classes to
> subclass it.
I actually had a sentence about that, but I removed it.
> Let DBCP focus on it's core responsibilities and provide easy
> hooks to allow logging, policy decisions, etc.
What hooks do you see as necessary in the base class(es)?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- "Noel J. Bergman" <no...@devtech.com> 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().
Agreed, but the way it was implemented was completely wrong. The behavior
should not have been in a superclass and forced unrelated classes to
subclass it.
> 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.
I agree. Let DBCP focus on it's core responsibilities and provide easy
hooks to allow logging, policy decisions, etc.
David
> DBCP may wish to
> provide abstract classes that facilitate specialization.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by "Noel J. Bergman" <no...@devtech.com>.
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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by Martin Poeschl <mp...@marmot.at>.
Juozas Baliuka wrote:
>I see it was a very big mistake to add AbandonedObjectPool, it was added for
>debugging but people misunderstanding it.
>I think we need to deprecate or remove it.
>
+1
was it part of the 1.0 release??
martin
>
>----- Original Message -----
>From: "Noel J. Bergman" <no...@devtech.com>
>To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
>Sent: Wednesday, July 02, 2003 7:43 AM
>Subject: RE: DBCP status?
>
>
>
>
>>>This entire thread has been filled with reasons to not support closing
>>>abandoned connections. If you need to have this behavior, you will need
>>>to customize DBCP for your apps because it should not be built in.
>>>
>>>
>>Actually, I would characterize it that abandoned connection handling is an
>>FAQ item *and* a polarizing one. Yes, there have been reasons to not
>>support closing abandoned connections. And just as loudly have been
>>
>>
>people
>
>
>>saying that they need it.
>>
>>Personally, I am still in a listening mode (plus I've been head down
>>
>>
>working
>
>
>>on a new server deployment). I've some thoughts, but I also knew that
>>
>>
>Serge
>
>
>>was off-line for a bit (and had a bunch of changes already on his local
>>drive), so I was waiting for him to return, too.
>>
>>--- Noel
>>
>>
>>---------------------------------------------------------------------
>>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
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- Juozas Baliuka <ba...@mwm.lt> wrote:
>
> I see it was a very big mistake to add AbandonedObjectPool, it was added
> for
> debugging but people misunderstanding it.
> I think we need to deprecate or remove it.
It's already deprecated.
David
>
> ----- Original Message -----
> From: "Noel J. Bergman" <no...@devtech.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Wednesday, July 02, 2003 7:43 AM
> Subject: RE: DBCP status?
>
>
> > > This entire thread has been filled with reasons to not support
> closing
> > > abandoned connections. If you need to have this behavior, you will
> need
> > > to customize DBCP for your apps because it should not be built in.
> >
> > Actually, I would characterize it that abandoned connection handling
> is an
> > FAQ item *and* a polarizing one. Yes, there have been reasons to not
> > support closing abandoned connections. And just as loudly have been
> people
> > saying that they need it.
> >
> > Personally, I am still in a listening mode (plus I've been head down
> working
> > on a new server deployment). I've some thoughts, but I also knew that
> Serge
> > was off-line for a bit (and had a bunch of changes already on his
> local
> > drive), so I was waiting for him to return, too.
> >
> > --- Noel
> >
> >
> > ---------------------------------------------------------------------
> > 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 status?
Posted by Juozas Baliuka <ba...@mwm.lt>.
I see it was a very big mistake to add AbandonedObjectPool, it was added for
debugging but people misunderstanding it.
I think we need to deprecate or remove it.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, July 02, 2003 7:43 AM
Subject: RE: DBCP status?
> > This entire thread has been filled with reasons to not support closing
> > abandoned connections. If you need to have this behavior, you will need
> > to customize DBCP for your apps because it should not be built in.
>
> Actually, I would characterize it that abandoned connection handling is an
> FAQ item *and* a polarizing one. Yes, there have been reasons to not
> support closing abandoned connections. And just as loudly have been
people
> saying that they need it.
>
> Personally, I am still in a listening mode (plus I've been head down
working
> on a new server deployment). I've some thoughts, but I also knew that
Serge
> was off-line for a bit (and had a bunch of changes already on his local
> drive), so I was waiting for him to return, too.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> This entire thread has been filled with reasons to not support closing
> abandoned connections. If you need to have this behavior, you will need
> to customize DBCP for your apps because it should not be built in.
Actually, I would characterize it that abandoned connection handling is an
FAQ item *and* a polarizing one. Yes, there have been reasons to not
support closing abandoned connections. And just as loudly have been people
saying that they need it.
Personally, I am still in a listening mode (plus I've been head down working
on a new server deployment). I've some thoughts, but I also knew that Serge
was off-line for a bit (and had a bunch of changes already on his local
drive), so I was waiting for him to return, too.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 3 Jul 2003 10:10 am, Craig R. McClanahan wrote:
> * If you don't use C-L, then you're either going to mandate
> some specific logging solution, or go without the benefits
> of logging in DBCP. Neither of those choices seems like
> a particularly good idea for a general purpose component.
You could always just add a listener architecture (as commons-pool already
has) and let anyone tie in arbitrary logging systems. It also has the
advantage that you don't have to worry about i18n as the implementation of
the listener does the i18n rather than the component that pushes it out to
the logger directly.
--
Cheers,
Peter Donald
*-------------------------------------------*
| "A handful of sand is an anthology of the |
| universe." -Albert Einstein |
*-------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 2 Jul 2003, Serge Knystautas wrote:
> [snip]
> > For some reason there are people against adding commons-logging to DBCP.
> > I don't know of any good reason not to.
>
> I think it's just because it's to keep the dependency tree thin. I
> haven't been burned yet, but in some of my apps I have dependencies on
> common libs from 5 higher level apps. I think eventually I'll get
> burned by 2 different apps requiring 2 different versions of
> commons-beanutils (just to pick one).
There's a couple of interesting notes about this to consider:
* If you are using other commons packages already, you're
very likely already committed to having commons-logging
available, as it is quite widely used. According to Gump's
cross reference charts, this seems to be true for lots of
other code as well (the itch that C-L scratches appears to
have been fairly common).
* If you don't use C-L, then you're either going to mandate
some specific logging solution, or go without the benefits
of logging in DBCP. Neither of those choices seems like
a particularly good idea for a general purpose component.
* If you really do need two different versions of something
like commons-beanutils, and the two versions are incompatible
with each other, then we've failed at a primary mission of
commons. In the particular case of beanutils, I know for a
fact that code needing only the APIs that were there in 1.0
will still work with 1.6.1, as I've lived through all of them
(dependence on particular bugs, of course, is another story :-).
But this is why Commons developers tend to be *very* conservative
about API changes that are not backwards compatible.
> Serge Knystautas
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by Serge Knystautas <se...@lokitech.com>.
David Graham wrote:
> I know how you feel. DBCP won't save you in these cases; training people
> in the simple ways of cleaning up resources properly will.
Yeah, I have plans on how to spot these issues better ahead of time.
Also, just starting to use p6spy as my magic bullet in the short-term...
> It is not the pool's responsibility to clean up after poorly coded apps.
> There is a clear separation of concerns between the pool and the app. The
> pool maintains the connections, the app properly uses the API and returns
> all connections when finished with them. There is no sound algorithm for
> determining when a connection is abandoned because DBCP doesn't have all
> the information required to make that decision. There are more but I've
> stated them previously.
I disagree about the lack of a sound algorithm, but I have come to agree
about this not being the pool's responsibility. So I agree the pooler
should just try to avoid opening connections each time (general pool
issues), and not get into these application issues.
> For some reason there are people against adding commons-logging to DBCP.
> I don't know of any good reason not to.
I think it's just because it's to keep the dependency tree thin. I
haven't been burned yet, but in some of my apps I have dependencies on
common libs from 5 higher level apps. I think eventually I'll get
burned by 2 different apps requiring 2 different versions of
commons-beanutils (just to pick one).
--
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 status?
Posted by David Graham <gr...@yahoo.com>.
--- Serge Knystautas <se...@lokitech.com> wrote:
> David Graham wrote:
> > This entire thread has been filled with reasons to not support closing
> > abandoned connections. If you need to have this behavior, you will
> need
> > to customize DBCP for your apps because it should not be built in.
> > However, any app that "needs" a connection pool to clean up after it
> is
> > highly suspect.
>
> Err... that's a bit of a blanket statement, and IMHO requiring an ideal
> world that I no longer am apart of.
>
> Most of my work these days is being the (Java/app) guru coming in
> pointing all the problems that are making the app server crash daily.
> (too much writing word docs and not enough code for my tastes, but kids
> to feed...)
>
> For one client, an errant search query can throttling Oracle because it
> hits some combination of terms that prompts a table scan. For another,
> I think the firewall that is dropping the close-tcp signal so the JVM
> thinks the connection is still waiting for something to happen. And on
> and on.
>
> I'm stuck dealing with lots of extremely "suspect" code.
I know how you feel. DBCP won't save you in these cases; training people
in the simple ways of cleaning up resources properly will.
> I think a lot
> of people downloading Tomcat and others will have similar issues with
> errant connections. I think this need is also what prompted the
> original attempt at abandoned connection recovery.
>
> As to how this thread has all these reasons to not close these kind of
> connections... I'm sorry, but I've followed every post and have missed
> them. I've seen (and argued) why you shouldn't try to return a
> connection in this state to the pool. There were also some issues with
> how it was not coded well in the first place and created unnecessarily
> complexity.
>
> If someone could quickly state a few reasons, I would be most
> appreciative.
It is not the pool's responsibility to clean up after poorly coded apps.
There is a clear separation of concerns between the pool and the app. The
pool maintains the connections, the app properly uses the API and returns
all connections when finished with them. There is no sound algorithm for
determining when a connection is abandoned because DBCP doesn't have all
the information required to make that decision. There are more but I've
stated them previously.
>
> > Many Jakarta projects use commons-logging to separate themselves from
> any
> > particular logging implementation. Implementing listeners is over
> > engineering what should be a simple solution. I believe commons-pool,
> on
> > which DBCP is based, supports listeners for various events.
>
> Dude, sorry... someone had balked on the listserv about adding
> commons-logging as a dependency, so this was another idea. If we can
> hook into commons-pool's listeners, then we can use that engineering for
For some reason there are people against adding commons-logging to DBCP.
I don't know of any good reason not to.
David
> free.
>
> --
> 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
>
__________________________________
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 status?
Posted by Serge Knystautas <se...@lokitech.com>.
David Graham wrote:
> This entire thread has been filled with reasons to not support closing
> abandoned connections. If you need to have this behavior, you will need
> to customize DBCP for your apps because it should not be built in.
> However, any app that "needs" a connection pool to clean up after it is
> highly suspect.
Err... that's a bit of a blanket statement, and IMHO requiring an ideal
world that I no longer am apart of.
Most of my work these days is being the (Java/app) guru coming in
pointing all the problems that are making the app server crash daily.
(too much writing word docs and not enough code for my tastes, but kids
to feed...)
For one client, an errant search query can throttling Oracle because it
hits some combination of terms that prompts a table scan. For another,
I think the firewall that is dropping the close-tcp signal so the JVM
thinks the connection is still waiting for something to happen. And on
and on.
I'm stuck dealing with lots of extremely "suspect" code. I think a lot
of people downloading Tomcat and others will have similar issues with
errant connections. I think this need is also what prompted the
original attempt at abandoned connection recovery.
As to how this thread has all these reasons to not close these kind of
connections... I'm sorry, but I've followed every post and have missed
them. I've seen (and argued) why you shouldn't try to return a
connection in this state to the pool. There were also some issues with
how it was not coded well in the first place and created unnecessarily
complexity.
If someone could quickly state a few reasons, I would be most appreciative.
> Many Jakarta projects use commons-logging to separate themselves from any
> particular logging implementation. Implementing listeners is over
> engineering what should be a simple solution. I believe commons-pool, on
> which DBCP is based, supports listeners for various events.
Dude, sorry... someone had balked on the listserv about adding
commons-logging as a dependency, so this was another idea. If we can
hook into commons-pool's listeners, then we can use that engineering for
free.
--
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 status?
Posted by David Graham <gr...@yahoo.com>.
--- Serge Knystautas <se...@lokitech.com> wrote:
> David Graham wrote:
> >>The approach I took was this....
> >>a) support an optional max-active time threshold, which means there is
> a
> >>
> >>time limit to how long a connection can be marked as in use.
> >
> >
> > There is a maxActive property of BasicDataSource that defines the
> maximum
> > number of open connections. Adding a time limit is reasonable if step
> b
> > is changed below.
> >
> >>b) if this threshold is exceeded, you close the connection. The value
>
> >>of trying to return it to the pool is minimal, while the downside of
> >>returning a mid-transaction/statement connection to a pool is very bad
>
> >>and nearly impossible to track down.
> >
> >
> > DBCP should not close connections that have been borrowed from the
> pool.
> > It should only log a possible error when the configured time limit has
> > been exceeded.
>
> I *need* the pooler to close connections that have been borrowed from
> the pool and forgotten to be closed.
> Can you give a) reasons why not to
>
> close them because of an optional parameter and b) suggested workaround?
This entire thread has been filled with reasons to not support closing
abandoned connections. If you need to have this behavior, you will need
to customize DBCP for your apps because it should not be built in.
However, any app that "needs" a connection pool to clean up after it is
highly suspect.
> > I'm ok with this as long the stack trace isn't logged like an
> exception.
> > It will be confusing for people to see a stack trace that isn't really
> > associated with an exception so the message should indicate that it's
> > identifying a possible connection leak location.
>
> I think there's a relunctance (including mine) to create a dependency on
>
> commons-logging (or another logger), so I was thinking about a
> PoolListener service.
Many Jakarta projects use commons-logging to separate themselves from any
particular logging implementation. Implementing listeners is over
engineering what should be a simple solution. I believe commons-pool, on
which DBCP is based, supports listeners for various events.
David
> There would be classes of events for:
> a) creating a connection
> b) grabbing a connection
> c) closing a connection
> d) a connection getting too old
>
> ...whatever else. I haven't thought through all the types of events,
> but I think allowing an optional listener(s) to attach to the pool would
>
> be even better than spewing log messages out. We'd want to provide at
> leats one debugging pool-listener that prints debug messages.
>
> --
> 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!?
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 status?
Posted by Serge Knystautas <se...@lokitech.com>.
David Graham wrote:
>>The approach I took was this....
>>a) support an optional max-active time threshold, which means there is a
>>
>>time limit to how long a connection can be marked as in use.
>
>
> There is a maxActive property of BasicDataSource that defines the maximum
> number of open connections. Adding a time limit is reasonable if step b
> is changed below.
>
>>b) if this threshold is exceeded, you close the connection. The value
>>of trying to return it to the pool is minimal, while the downside of
>>returning a mid-transaction/statement connection to a pool is very bad
>>and nearly impossible to track down.
>
>
> DBCP should not close connections that have been borrowed from the pool.
> It should only log a possible error when the configured time limit has
> been exceeded.
I *need* the pooler to close connections that have been borrowed from
the pool and forgotten to be closed. Can you give a) reasons why not to
close them because of an optional parameter and b) suggested workaround?
> I'm ok with this as long the stack trace isn't logged like an exception.
> It will be confusing for people to see a stack trace that isn't really
> associated with an exception so the message should indicate that it's
> identifying a possible connection leak location.
I think there's a relunctance (including mine) to create a dependency on
commons-logging (or another logger), so I was thinking about a
PoolListener service. There would be classes of events for:
a) creating a connection
b) grabbing a connection
c) closing a connection
d) a connection getting too old
...whatever else. I haven't thought through all the types of events,
but I think allowing an optional listener(s) to attach to the pool would
be even better than spewing log messages out. We'd want to provide at
leats one debugging pool-listener that prints debug messages.
--
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 status?
Posted by Juozas Baliuka <ba...@mwm.lt>.
> > b) if this threshold is exceeded, you close the connection. The value
> > of trying to return it to the pool is minimal, while the downside of
> > returning a mid-transaction/statement connection to a pool is very bad
> > and nearly impossible to track down.
>
> DBCP should not close connections that have been borrowed from the pool.
> It should only log a possible error when the configured time limit has
> been exceeded.
>
> > c) support an optional debug step that will create a Throwable when
> > getConnection is called. Then if the max-active threshold is hit, we
> > can print the stack trace of where the aged connection was grabbed, and
> > in development/testing, quickly resolve the errant connection.
>
> I'm ok with this as long the stack trace isn't logged like an exception.
> It will be confusing for people to see a stack trace that isn't really
> associated with an exception so the message should indicate that it's
> identifying a possible connection leak location.
I log message if the active-connections = max-connections,
it helps to configure pools (increase max-connections or decrease
max-threads).
"finally close" is not any kind of problem, it is in single place per
application, if resource management is well designed.
It can be usefull for crapy applications only, I do not think we need some
kind of special support for crap in commons.
>
> David
>
> >
> > Does this seem reasonable?
> >
> > --
> > 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!?
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Re[2]: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- Anton Tagunov <at...@mail.cnt.ru> wrote:
> Hello David!
>
> DG> DBCP should not close connections that have been borrowed from the
> pool.
> DG> It should only log a possible error when the configured time limit
> has
> DG> been exceeded.
>
> What do you think, should this overtimed connection still be
> considered "active" for the purpose of enforsing
> WHEN_EXHAUSTED_FAIL or
> WHEN_EXHAUSTED_BLOCK?
Connections that have been checked out of the pool should always be
counted in the WHEN_EXHAUSTED_FAIL check regardless of the amount of time
they've been checked out.
David
>
> Should the active connection counter rather be decreased
> by 1 once a connection overtimes?
>
> SK> c) support an optional debug step that will create a Throwable when
> SK> getConnection is called. Then if the max-active threshold is hit,
> we
> SK> can print the stack trace of where the aged connection was grabbed,
> and
> SK> in development/testing, quickly resolve the errant connection.
>
> DG> I'm ok with this as long the stack trace isn't logged like an
> exception.
> DG> It will be confusing for people to see a stack trace that isn't
> really
> DG> associated with an exception so the message should indicate that
> it's
> DG> identifying a possible connection leak location.
>
> We can envent some special exception, something like
>
> ConnectionOvertimeDetected
>
> or smth better, but give it such a descriptive name and message
> that would save the user from confusion.
>
> Or we could create a cascading exception that would have
> a getCause() method that would return the original exception
> as the root cause (it is in some sense a root cause)
>
> - Anton
>
>
> ---------------------------------------------------------------------
> 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[2]: DBCP status?
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello David!
DG> DBCP should not close connections that have been borrowed from the pool.
DG> It should only log a possible error when the configured time limit has
DG> been exceeded.
What do you think, should this overtimed connection still be
considered "active" for the purpose of enforsing
WHEN_EXHAUSTED_FAIL or
WHEN_EXHAUSTED_BLOCK?
Should the active connection counter rather be decreased
by 1 once a connection overtimes?
SK> c) support an optional debug step that will create a Throwable when
SK> getConnection is called. Then if the max-active threshold is hit, we
SK> can print the stack trace of where the aged connection was grabbed, and
SK> in development/testing, quickly resolve the errant connection.
DG> I'm ok with this as long the stack trace isn't logged like an exception.
DG> It will be confusing for people to see a stack trace that isn't really
DG> associated with an exception so the message should indicate that it's
DG> identifying a possible connection leak location.
We can envent some special exception, something like
ConnectionOvertimeDetected
or smth better, but give it such a descriptive name and message
that would save the user from confusion.
Or we could create a cascading exception that would have
a getCause() method that would return the original exception
as the root cause (it is in some sense a root cause)
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- Serge Knystautas <se...@lokitech.com> wrote:
> David Graham wrote:
> > The problem was that DBCP was trying to track and recover abandoned
> > connections. This isn't just an implementation problem, it's a
> philosophy
> > problem. Pool semantics dictate that client applications behave
> properly
> > when checking out and returning pool resources. The pool is
> absolutely
> > not responsible for fixing poorly behaving applications. This led to
> > bugs, questions, convoluted inheritance hierachies/code, and promoted
> the
> > idea that users didn't have to bother writing their applications
> properly
> > because the pool would fix their apps for them.
> >
> > The pool should keep track of how long a connection has been checked
> out
> > and log a message when it passes some configurable threshold but it
> should
> > never try to grab the connection back from the application.
>
> I agree trying to recover connections is bad. I've found it leads to
> problems that don't show up during a test phase become very confusing
> and challenging problems in production once under high-load.
>
> The approach I took was this....
> a) support an optional max-active time threshold, which means there is a
>
> time limit to how long a connection can be marked as in use.
There is a maxActive property of BasicDataSource that defines the maximum
number of open connections. Adding a time limit is reasonable if step b
is changed below.
> b) if this threshold is exceeded, you close the connection. The value
> of trying to return it to the pool is minimal, while the downside of
> returning a mid-transaction/statement connection to a pool is very bad
> and nearly impossible to track down.
DBCP should not close connections that have been borrowed from the pool.
It should only log a possible error when the configured time limit has
been exceeded.
> c) support an optional debug step that will create a Throwable when
> getConnection is called. Then if the max-active threshold is hit, we
> can print the stack trace of where the aged connection was grabbed, and
> in development/testing, quickly resolve the errant connection.
I'm ok with this as long the stack trace isn't logged like an exception.
It will be confusing for people to see a stack trace that isn't really
associated with an exception so the message should indicate that it's
identifying a possible connection leak location.
David
>
> Does this seem reasonable?
>
> --
> 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!?
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 status?
Posted by Serge Knystautas <se...@lokitech.com>.
David Graham wrote:
> The problem was that DBCP was trying to track and recover abandoned
> connections. This isn't just an implementation problem, it's a philosophy
> problem. Pool semantics dictate that client applications behave properly
> when checking out and returning pool resources. The pool is absolutely
> not responsible for fixing poorly behaving applications. This led to
> bugs, questions, convoluted inheritance hierachies/code, and promoted the
> idea that users didn't have to bother writing their applications properly
> because the pool would fix their apps for them.
>
> The pool should keep track of how long a connection has been checked out
> and log a message when it passes some configurable threshold but it should
> never try to grab the connection back from the application.
I agree trying to recover connections is bad. I've found it leads to
problems that don't show up during a test phase become very confusing
and challenging problems in production once under high-load.
The approach I took was this....
a) support an optional max-active time threshold, which means there is a
time limit to how long a connection can be marked as in use.
b) if this threshold is exceeded, you close the connection. The value
of trying to return it to the pool is minimal, while the downside of
returning a mid-transaction/statement connection to a pool is very bad
and nearly impossible to track down.
c) support an optional debug step that will create a Throwable when
getConnection is called. Then if the max-active threshold is hit, we
can print the stack trace of where the aged connection was grabbed, and
in development/testing, quickly resolve the errant connection.
Does this seem reasonable?
--
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 status?
Posted by David Graham <gr...@yahoo.com>.
--- "Noel J. Bergman" <no...@devtech.com> wrote:
> > > - Better support/debugging for forcing connections closed after
> being
> > > open for "too long"
>
> > This is exactly what got DBCP into trouble in the past. I'm -1 on
> > providing any ability in DBCP to close lost connections. DBCP should
> > provide the ability to *log* when it detects a resource leak but the
> > application is responsible for the health of the pool.
>
> I understand your view, but do you believe that there is no possible
> solution? If it is just an implementation concern, I'd just as soon see
> what solution someone comes up with. In your opinion, what are/were the
> problems in handling "abandoned" connections in DBCP?
The problem was that DBCP was trying to track and recover abandoned
connections. This isn't just an implementation problem, it's a philosophy
problem. Pool semantics dictate that client applications behave properly
when checking out and returning pool resources. The pool is absolutely
not responsible for fixing poorly behaving applications. This led to
bugs, questions, convoluted inheritance hierachies/code, and promoted the
idea that users didn't have to bother writing their applications properly
because the pool would fix their apps for them.
The pool should keep track of how long a connection has been checked out
and log a message when it passes some configurable threshold but it should
never try to grab the connection back from the application.
David
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > - Better support/debugging for forcing connections closed after being
> > open for "too long"
> This is exactly what got DBCP into trouble in the past. I'm -1 on
> providing any ability in DBCP to close lost connections. DBCP should
> provide the ability to *log* when it detects a resource leak but the
> application is responsible for the health of the pool.
I understand your view, but do you believe that there is no possible
solution? If it is just an implementation concern, I'd just as soon see
what solution someone comes up with. In your opinion, what are/were the
problems in handling "abandoned" connections in DBCP?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP status?
Posted by David Graham <gr...@yahoo.com>.
--- Tim Funk <fu...@joedog.org> wrote:
> Tomcat (5) uses BasicDataSourceFactory (but this can be overridden via a
>
> system property).
>
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/ResourceFactory.java
>
>
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/globalresources.html
>
> Things I'd like to see (but stayed quiet since I don't have time just
> yet to
> make my wishes come true)
> - Better support/debugging for forcing connections closed after being
> open
> for "too long"
This is exactly what got DBCP into trouble in the past. I'm -1 on
providing any ability in DBCP to close lost connections. DBCP should
provide the ability to *log* when it detects a resource leak but the
application is responsible for the health of the pool.
David
> - Code walkthrough so everything is JMX friendly, from there - that
> should
> let me do the following:
> -- Query all datasources (quantity)
> -- See the following stats for each datasource
> - Open connections
> - Borrowed Connections
> - High water mark
> - Average connection open time (or other similar stats)
> - Number of connections force closed
> - Limited list (with stack trace) of connections which kept conns
> open
> - Limited list (with stack trace) of worst performing connections
> - For each connection borrowed, show all its assests such as open
> result
> sets, statements, the current query being exectued, is the query
> currently
> being executed, how long has the query been running
>
>
> DBCP already exposed some of these stats. I first looked at dbcp a long
> time
> ago when switching servlet engines where the old one provided a database
> pool
> but I dodn't have time to retrofit my legacy code into dbcp. So I had to
>
> write my own database pool which does much of the above (excluding JMX).
> While I rarely query the stats above - occasionally they are invaluable.
>
> My 2 cents, but feel free to ignore me since I won't be able to help out
> in
> the short term.
>
> -Tim
>
> Anton Tagunov wrote:
> >
> > SK> Anybody know what Tomcat is using at this point?
> > Indeed would be interesting to see that :-)
> >
> > - Anton
>
>
> ---------------------------------------------------------------------
> 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 status?
Posted by Tim Funk <fu...@joedog.org>.
Tomcat (5) uses BasicDataSourceFactory (but this can be overridden via a
system property).
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/ResourceFactory.java
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/globalresources.html
Things I'd like to see (but stayed quiet since I don't have time just yet to
make my wishes come true)
- Better support/debugging for forcing connections closed after being open
for "too long"
- Code walkthrough so everything is JMX friendly, from there - that should
let me do the following:
-- Query all datasources (quantity)
-- See the following stats for each datasource
- Open connections
- Borrowed Connections
- High water mark
- Average connection open time (or other similar stats)
- Number of connections force closed
- Limited list (with stack trace) of connections which kept conns open
- Limited list (with stack trace) of worst performing connections
- For each connection borrowed, show all its assests such as open result
sets, statements, the current query being exectued, is the query currently
being executed, how long has the query been running
DBCP already exposed some of these stats. I first looked at dbcp a long time
ago when switching servlet engines where the old one provided a database pool
but I dodn't have time to retrofit my legacy code into dbcp. So I had to
write my own database pool which does much of the above (excluding JMX).
While I rarely query the stats above - occasionally they are invaluable.
My 2 cents, but feel free to ignore me since I won't be able to help out in
the short term.
-Tim
Anton Tagunov wrote:
>
> SK> Anybody know what Tomcat is using at this point?
> Indeed would be interesting to see that :-)
>
> - Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org