I think this is reasonable... of course I am then going to desire and good
implementation of equals() on PoolableConnection ;-)
Which I suppose could be as simple as this:
public boolean equals(Object obj) {
if(this.hashCode() == obj.hashCode())
return true;
return false;
}
or even this:
public boolean equals(Object obj) {
if(this == obj)
return true;
return false;
}
-- Since it IS the same object that we're worried about.
James
At 4/2/2002 04:52 PM -0600, you wrote:
>To clarify, I think it's pretty much as simple as this:
>
>public class CheckingObjectPool extends GenericObjectPool {
> public void returnObject(Object obj) throws Exception {
> if(_pool.contains(obj)) {
> throw new Exception(obj + " is already in the pool.");
> }
> }
>}
>
>to extend GenericObjectPool with this behavior.
>
>-----Original Message-----
>From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 01, 2002 12:25 PM
>To: 'Jakarta Commons Developers List'
>Subject: RE: [POOL] Bug
>
>
> > This could easily be done by doing a "contains()"
> > check on the collection that backs the pool before
> > adding the object to it.
>
>If and only if the equality method identifies unique instances of objects
>within the pool.
>
>You could implement a [Keyed]ObjectPool to do this, or perhaps better still,
>implement it via the passivateObject method of [Keyed]PoolableObjectFactory.
>Then it would be tied to the top of object being pooled, when you could
>enforce a meaningful contains() method.
>
>I'm not sure it makes sense to do this check in the general case, since, as
>you note:
>
> > if there is code that returns the object to the pool more
> > than once, then that code itself is buggy,
>
>What do the rest of you think?
>
>-----Original Message-----
>From: James House [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 01, 2002 10:26 AM
>To: [EMAIL PROTECTED]
>Subject: [POOL] Bug
>
>
>
>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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
