commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [pool] equal instances
Date Thu, 09 Jun 2011 08:19:38 GMT
On 09/06/2011 04:39, Phil Steitz wrote:
> Code in trunk now does not work when distinct pooled instances are
> equal - i.e., if a factory produces instances A and B and
> A.equals(B), this causes problems.   I think this situation should
> be allowed - i.e. it is an unacceptable restriction to put on object
> factories that distinct the poolable objects they produce be
> distinguishable under equals.  This would be a new requirement for
> [pool] and I don't think we should require it.  What do others think?

As I start to answer this, I can see a very long response developing. I
will do my best to keep it short. That may mean I gloss over some aspects.

The requirement that objects obtained from the factories meet
A.equals(B) == false greatly simplifies the implementation of a number
of requirements. Let me explain by using a single requirement although
there are a number of other requirements that have very similar

The Requirement:
It shall not be possible to return an object to the pool more than once.

The pool maintains a list of idle objects. The simplest implementation
of the above requirement is to test if any returned object already
exists in the pool. This doesn't catch all scenarios but it is a start.

If we know that for objects obtained from the factories A.equals(B) ==
false then we can use a HashSet to store idle instances and it is very
easy to determine if the object being returned exists in the set of idle
objects. This makes determining if the object is being returned twice
relatively inexpensive. It also makes a reasonable multi-threaded
implementation possible.

If we have to rely on testing A!=B then we have no choice but to iterate
through the idle objects. This is slow and would probably require at
least a small sync. In the multi-threaded case this is going to be
really slow.

An alternative solution to handle factories where A.equals(B) == true
would be to wrap the object in another object where A.equals(B) ==
false. This would make usage of the pool by clients more awkward as they
would need to unwrap the object.

We can't add an intermediate layer that maps objects to wrappers since
that layer would need to maintain a mapping of objects to wrappers and
the only efficient way to do that is with a HashMap which requires
A.equals(B) == false.

For the sort of functionality we want to have in pool2, I believe we
need to be able to use HashMap and derivatives where the objects are
used as keys. While implementations of some of the features may be
possible without this, I don't see a way to implement them without code
that is significantly more complex than pool1. One of the big advantages
of the pool2 code is that it is - in my view - much easier to understand
what is going on. I suggest that folks look at the current pool2
implementation and try and figure out how to replace all cases where
pooled objects are used as keys in HashMaps etc. I think it would be
very difficult / impossible.


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

View raw message