commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: DBCP status?
Date Tue, 01 Jul 2003 02:18:56 GMT
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


Mime
View raw message