Dealing with unreleased pool objects

[Charles Hudak <CH...@arrowheadgrp.com>]

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

Re: Dealing with unreleased pool objects

[Dirk Verbeeck <di...@pandora.be>]

Tomcat uses BasicDataSource in the DBCP component 
(http://jakarta.apache.org/commons/dbcp/) as its default datasource implementation.
Like you said it has support for abandoned connections.
See 
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/AbandonedObjectPool.java?rev=HEAD
for the abandoned pool implementation. (extending the GenericObjectPool)

For now it's in the DBCP package but we can always make it more generic and move 
       it to the Pool package (that is one of the reasons why it is already 
deprecated)

Improvements are always welcome ;-)

Regards
Dirk

Charles Hudak wrote:

> 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