commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: DBCP status?
Date Wed, 02 Jul 2003 13:49:04 GMT
--- Serge Knystautas <sergek@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


Mime
View raw message