> -----Original Message----- > From: Phil Steitz [mailto:phil.ste...@gmail.com] > Sent: Friday, July 02, 2010 18:25 > To: Commons Developers List > Subject: Re: [pool] deprecation of setFactory methods > > 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...
And gone... IMO, I see this type of method making more sense when generics are added to the project. Tangent: If I have a pool of <Widget> (through generics), I can see replacing the factory with another widget factory. But just saying that I can plug in a new factory that produces "Object" feels off. It also feels like an advanced feature that can greatly complicate an implementation: I should be able to define what happens when I plug in a factory (nuke pooled objects, or don't.) So this might better be handled in a specialized sub-interface. 2c, Gary > > 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
