[ 
https://issues.apache.org/jira/browse/POOL-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295157#comment-14295157
 ] 

Phil Steitz commented on POOL-284:
----------------------------------

It's probably worth looking carefully at what performance (and bug-generating) 
impact would be for 

1. Fully sync-protected IdentityHashMap
2. Selective syncs added to create / destroy
3. IdentityHashcodeWrapper

I was tempted to add 4. hack internals of IdentityHashMap to get something 
protected enough for our use, but that is probably a *bad idea*

If 1 and 3 are both noticeably bad and 2 is too scary (or also bad), then 
probably the PoolUtils approach is best.  In any case, we should clarify 
javadoc to make current behavior clear.

> "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)

Reply via email to