commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] equal instances
Date Thu, 09 Jun 2011 13:50:48 GMT
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


Mime
View raw message