Hi All: I would like to understand the requirements better:
- Is this for pool1 and/or pool2? It seems like a big change for pool1 that should be in a 1.6 (not 1.5.x) - Do we have real user stories for this new req? Or is this a theoretical nicety? Thank you, Gary On Thu, Jun 9, 2011 at 9:50 AM, sebb <seb...@gmail.com> 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 > > Could of course use == to disambiguate such objects. > > > 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 > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
