2011/6/9 Mark Thomas <ma...@apache.org>: > 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.
</snip> 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. WDYT? Julien > > 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
