commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [pool] 2.0 factory interfaces WAS: Re: svn commit: r1506685 - in /commons/proper/pool/trunk/src: main/java/org/apache/commons/pool2/ main/java/org/apache/commons/pool2/impl/ test/java/org/apache/commons/pool2/ test/java/org/apache/commons/pool2/impl/ test/java/org/apache/commons/pool2/perfo...
Date Sun, 04 Aug 2013 14:24:24 GMT
On 03/08/2013 17:15, Phil Steitz wrote:
> On 7/30/13 9:16 AM, Phil Steitz wrote:
>> I have started working on this.  Should have something to commit at
>> least for GOP in the next day or two.
> 
> I am stuck on SoftReferenceObectPool. 

:(

> I have been able to handle
> everything else collapsing down to just Pooled(Keyed)ObjectFactory /
> Base(Keyed)ObjectPool.

Excellent.

> To stick with (and get factory / monitoring
> benefits of) PooledObjectFactory / PooledObjects, I need to create a
> version of DefaultPooledObject that wraps SoftReferences and these
> have to be mutable - i.e., when an instance is returned a new soft
> reference is created and stored in the pool, but we want to maintain
> PooledObject state.  To do this, I need to be able to recognize the
> returning object.  I could do this by searching the pool, but that
> will cost something.  On the other hand, the lack of search now
> means returnObject is not idempotent (like it is in the rest of the
> 2.0 pools).  Multiple returns will put multiple soft references to
> the same object in the pool.
> 
> So, I would appreciate some feedback on the following options:
> 
> 1) Add a search for the returning object and create a
> PooledSoftReference subclass of DefaultPooledObject within
> SoftReferencePool to be stored in the pool.
> 
> 2) Keep PoolableObjectFactory just for this pool and leave it alone,
> adding a warning to returnObject (not a new issue, just different
> from other 2.0 pools).

I think the benefits of the monitoring justify adding the search so my
preference is for option 1.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message