--- Serge Knystautas <[EMAIL PROTECTED]> wrote: > David Graham wrote: > >>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. > > I *need* the pooler to close connections that have been borrowed from > the pool and forgotten to be closed. > Can you give a) reasons why not to > > close them because of an optional parameter and b) suggested workaround?
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. > > 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. > > I think there's a relunctance (including mine) to create a dependency on > > commons-logging (or another logger), so I was thinking about a > PoolListener service. 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. David > There would be classes of events for: > a) creating a connection > b) grabbing a connection > c) closing a connection > d) a connection getting too old > > ...whatever else. I haven't thought through all the types of events, > but I think allowing an optional listener(s) to attach to the pool would > > be even better than spewing log messages out. We'd want to provide at > leats one debugging pool-listener that prints debug messages. > > -- > 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]
