commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: DBCP status?
Date Mon, 30 Jun 2003 03:31:03 GMT
David Graham wrote:
> --- "Noel J. Bergman" <> wrote:
>>I hope that you have not gotten the impression that I am arguing with
> 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: 
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.


> 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
>>the idea of recovering connections, and I wanted to hear what people
>>	--- Noel
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message