commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [pool] equal instances
Date Thu, 09 Jun 2011 14:48:35 GMT
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 <sebbaz@gmail.com> wrote:

> On 9 June 2011 14:41, Mark Thomas <markt@apache.org> wrote:
> > On 09/06/2011 10:01, Julien Aymé wrote:
> >> 2011/6/9 Mark Thomas <markt@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message