[
https://issues.apache.org/jira/browse/POOL-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294485#comment-14294485
]
Bernd Eckenfels commented on POOL-284:
--------------------------------------
I think both (this and POOL-283) is by design of the generic implementation:
users need to have stable, idendity-preserving equals() and hashcode()
implementations (like with normal maps, too).
It might be possible to check for idendity and accept them anyway, but since
the hashCode has to be stable for managing them, I dont think it helps much.
I havent found this requirement documented in the Javadoc, not of the
API/interfaces or the generic implementation. One or both should state that. (I
wonder if a implementation based on IdendityHashMap for the generic pool would
be fine or if this would be a more specific pool).
> "Returned object not currently part of this pool" when using mutable objects
> ----------------------------------------------------------------------------
>
> Key: POOL-284
> URL: https://issues.apache.org/jira/browse/POOL-284
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 2.2
> Reporter: Valentin Mayamsin
>
> I'm using pool to reuse expensive Sets (storing millions of items). Here is a
> test which fails:
> {code}
> GenericObjectPoolConfig config = new GenericObjectPoolConfig ();
> GenericObjectPool<Set> aPool = new GenericObjectPool<> ( new
> BasePooledObjectFactory<Set> ()
> {
> @Override
> public Set create () throws Exception
> {
> return new HashSet();
> }
> @Override
> public PooledObject<Set> wrap ( Set o )
> {
> return new DefaultPooledObject<> ( o );
> }
> @Override
> public void passivateObject ( PooledObject<Set> p ) throws
> Exception
> {
> p.getObject ().clear ();
> super.passivateObject ( p );
> }
> }, config );
> Set set = aPool.borrowObject ();
> set.add ( new Object () );
>
> aPool.returnObject ( set );
> {code}
> This is because GenericObjectPool uses a HashMap<Object, PooledObject> to
> correlate objects and state. HashMap stores objects correlated to their
> hashCode. So in case object's state change then hashCode will change, thus
> Map will fail to correlate this object since it stores old hashCode
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
