commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] deprecation of setFactory methods
Date Sat, 03 Jul 2010 10:13:21 GMT
On 3 July 2010 02:25, Phil Steitz <phil.steitz@gmail.com> wrote:
> Phil Steitz wrote:
>> setFactory belongs to the top level ObjectPool and KeyedObjectPool
>> interfaces.  I would like to deprecate these methods uniformly (to
>> be removed in pool 2.0) - removing them from the top level
>> interfaces and deprecating all implementations. There are two
>> reasons for this:
>>
>> 1. Good semantics for this method are hard to define.  The interface
>> docs state only that the method may not always be supported and may
>> throw RTEs.  GenericObjectPool throws IllegalStateException if the
>> method is invoked when there are borrowed objects out and destroys
>> all idle instances as a side effect when it succeeds.  That is a
>> reasonable approach, but begs the question why not just clear the
>> existing pool and create a new one.  It seems reasonable to me that
>> an invariant of an object pool should be instance homogeneity wrt
>> object factory.  This is what GOP enforces.  So why not just make
>> the factory immutable?
>>
>> 2. If the factory is mutable, threadsafety requires that access to
>> it be synchronized.  Currently, we are inconsistent on this.  Adding
>> synchronization to "fix" this would have significant performance
>> impacts.
>>
>> Before proceeding with wholesale deprecation, I would like to get
>> some feedback.  In particular, I would like to make sure that there
>> are no valid use cases for setFactory applied to currently
>> implemented pools. Thanks in advance.
>
> Going once, going twice...

OK by me.

I cannot think of any reason why one would want to change the pool
factory after creation.

If it really did turn out to be necessary, I think one could get round
it by creating the pool with a changeable pool factory.
The factory would of course be responsible for its own thread safety
across changes.

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