--- Serge Knystautas <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
