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. James -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
