commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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 Thu, 08 Aug 2013 03:07:50 GMT
On 8/4/13 9:27 AM, Phil Steitz wrote:
> On 8/4/13 7:24 AM, Mark Thomas wrote:
>> 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.
> Drat, I thought I was going to get away with 2) - he he.  I will
> plow ahead with 1 :)

OK, done now.  All tests pass.  I am just cleaning up javadoc and
will commit in next 24 hours.  I have not added JMX stuff to
SoftReferenceObjectPool, but will do that after committing the
initial refactoring.  I also did not clean up the complete sync and
spurious notifies in SoftReferenceObjectPool.  That can also be
looked at next.  More observations on this class to follow post-commit.

Phil
>
> Phil
>> 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