commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Hudak <CHu...@arrowheadgrp.com>
Subject Dealing with unreleased pool objects
Date Wed, 05 Nov 2003 18:55:04 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message