On 3 July 2010 02:25, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
