commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [pool] deprecation of setFactory methods
Date Sat, 03 Jul 2010 10:13:21 GMT
On 3 July 2010 02:25, Phil Steitz <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message