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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
