commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James House <>
Subject [POOL] Bug
Date Mon, 01 Apr 2002 16:26:19 GMT

I've ran into another bug with Pool / DBCP.

The problem lies in GenericObjectPool's returnObject() method.

There is no check to see if the object has already been returned, it simply 
adds the object back into the pool.

If the object has already been returned, then the object now appears two or 
more times in the pool.  This leads to serious problems.  For one, it leads 
to multiple threads "borrowing" the same object at the same time.  It also 
makes the pool "fill up" which causes very serious problems -- once the 
maxIdle pool count is reached (which happens quickly in this scenario), the 
pool starts "tossing" out objects that are being returned.  It does so by 
calling "destroyObject".  The problem with this is that the object (in this 
case, a DB connection) gets destroyed, but there are multiple pointers to 
it still in the pool!  - the next time the object is borrowed from the pool 
it is completely invalid! (the connection has been closed).

I understand that if there is code that returns the object to the pool more 
than once, then that code itself is buggy, however I think there should 
also be real safeguards in the pool (returnObject()) that disallow the same 
object to be in the pool multiple times.  This could easily be done by 
doing a "contains()" check on the collection that backs the pool before 
adding the object to it.  If the object is found to already be in the pool, 
an exception should be thrown so that the code utilizing the pool can be 
corrected.  Perhaps "contains()" is not the most efficient way to do the 
check (if the pool is large) -- but it's probably the most quick and easy 
way to make the fix, as it simply adds 2 lines of code:  a line to test the 
condition, and another line to throw an exception.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message