The code was buggy and added complexity both in and out of the AbandonedConnectionPool.
Some would argue that recovering from programmer error is not an appropriate role for a component like DBCP, and for what it's worth, I think I'm probably one of those. That said, I think changing dbcp/pool to be more compositional and less extend-to-customize-oriented would be a good move all around, and should make it possible to add abandoned object recovery (or abandoned object logging, or a host of other things) as a decorator--which should make it orthogonal to the other implementations/concerns. - Rod <http://radio.weblogs.com/0122027/> On Sat, 28 Jun 2003, Noel J. Bergman 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? > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
