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 Tue, 01 Jul 2003 13:43:00 GMT
--- Serge Knystautas <sergek@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


Mime
View raw message