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. 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
