commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Aymé <>
Subject Re: [pool] equal instances
Date Thu, 09 Jun 2011 09:01:36 GMT
2011/6/9 Mark Thomas <>:
> 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
> consequences.
> 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.


And what about using an IdentityHashSet (or IdentityHashMap) to store
idle objects.
This would meet the Requirement without having to enforce A.equals(B) == false.


> 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.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message