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] deprecation of setFactory methods
Date Sat, 03 Jul 2010 01:25:19 GMT
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...

Phil
> 
> Phil
> 


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


Mime
View raw message