--- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: > > > - Better support/debugging for forcing connections closed after > being > > > open for "too long" > > > This is exactly what got DBCP into trouble in the past. I'm -1 on > > providing any ability in DBCP to close lost connections. DBCP should > > provide the ability to *log* when it detects a resource leak but the > > application is responsible for the health of the pool. > > I understand your view, but do you believe that there is no possible > solution? If it is just an implementation concern, I'd just as soon see > what solution someone comes up with. In your opinion, what are/were the > problems in handling "abandoned" connections in DBCP?
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. David > > --- Noel > > > --------------------------------------------------------------------- > 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]
