Howdy, Tomcat 4.x uses DBCP 2.0 and that version of DBCP supports reaping and logging of abandoned connections. DBCP 2.1 marks all these methods as deprecated for reasons that are unknown to me, but I bet you could find out by searching this list's archives. Hopefully DBCP 2.2 and later will provide alternative implementations of the abandoned connection functionality, as I agree these are useful.
Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Charles Hudak [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 05, 2003 1:55 PM >To: '[EMAIL PROTECTED]' >Subject: Dealing with unreleased pool objects > >I've been reviewing the source code as I've been contemplating having my >existing pool implementations delegate to the commons pool implementations. > >One issue that I have, however, is that the current pool implementations do >not appear to deal with 'abandoned' pool objects. We all agree that clients >of the pools should always release objects that they have acquired from the >pool but my experience shows that the mistake of not doing this is all too >common. Whether blatently forgetting to release the objects or not properly >using a try/finally construct to make sure that objects are released even >if >an exception is thrown, I have found this problem throughout our >application. > >This is particularly troublesome when using DB pools in an application >container like Weblogic. The older version of WL that we are running (5.1) >does not deal with abandoned connection objects. They are never reclaimed >by >the pool so in the case of this common programming bug, the pool either >grows unchecked or grows to its limit and then starts throwing exceptions >because no more connections are available. > >It looks like the GenericObjectPool imlementation doesn't actually store >references to the 'used' objects which would theoretically deal with >abandoned objects. Unfortunately, it keeps a count of the number of objects >that are 'active' so if an object is abandoned, the active count will >continue to grow, which would cause problems if you put a cap on the number >of active objects. > >I would suggest holding the 'active' objects in an 'active' list and having >the cleaner thread evict abandoned objects in this list if they are past >some expiration time. This is what I have done in my own pool >implementations and I find that it eliminates alot of hard to find bugs, >although it doesn't fix the poor client code that caused the problem. > >Does anyone else see a need for this kind of behavior? I'm pretty sure that >the newer implementations of the tomcat DB pooling have this feature and >they will even provide back traces in the log to track which client code is >misbehaving. > >Thanks > >Charles Hudak >Software Engineering Manager >Arrowhead General Insurance/YouZoom, Inc. > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
