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]
