On 09/06/2011 14:50, sebb wrote: > On 9 June 2011 14:41, Mark Thomas <ma...@apache.org> wrote: >> On 09/06/2011 10:01, Julien Aymé wrote: >>> 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. >> >> That would be one of the aspects I glossed over. They aren't always >> maps/sets and they need to support concurrent access by multiple threads. >> >> A wrapper for pooled objects that uses System.identityHashCode(Object) >> may be a possible solution that isn't too complex. It would add a >> requirement for the pool to unwrap/wrap objects on borrow/return. I can >> look at this if folks think the new restriction on factories is >> unacceptable. > > Note that System.identityHashCode() is not necessarily unique: > https://issues.apache.org/jira/browse/LANG-459
I think I might be able to work around that by asking the factory for another object if it issues one with an identityHashCode we have already seen. > Could of course use == to disambiguate such objects. That would have some nasty performance implications and may also needs some syncs in a few places. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
