On 14/12/2011 09:23, sebb wrote: > I'm trying to establish the mutability needs of the > [Keyed]ObjectPoolFactory implementations, i.e. > > Generic[Keyed]ObjectPoolFactory > > I've looked at DBCP 1.4, which uses POOL 1.x.
You need to look at DBCP trunk that uses POOL 2. There has been quite a lot of refactoring. > DBCP 1.4 currently creates an instance of > GenericKeyedObjectPoolFactory, which it then uses via the interface > KeyedObjectPoolFactory. > [This is in the class BasicDataSource.] > The additional GKOPF getters, and the protected mutable variables are > not actually used by DBCP; it only needs to create the instance of > KeyedObjectPoolFactory. > There is no indication that DBCP needs to change or even inspect the > factory settings once it is created. > > The factory setters were added in POOL2; if they were not needed for > DBCP in POOL 1.X, so are they really needed in POOL 2.x? > > I already removed them as part of making the classes thread-safe; the > question is, are the setters now needed in POOL 2? > If so, they can be restored, but synch./volatile will need to be > added, as I assume the factories must be thread-safe. > > Indeed, are the getters even needed? The Pool 1.x code did provide > getters, but AFAICT they were not used by DBCP. > > The calling code knows what it used to create the factory, and the > factory is subsequently used as an instance of the interface - which > only provides the createPool() method. > Is there really a need for other code to find out what the original > factory settings were? > > Can the getters be removed? > Do the setters have to be restored? The factory is little more than a wrapper for the G[K]OPConfig and [K]PoolableObjectFactory. I think there are three options. 1. Drop getters and setters and keep it as a simple, immutable wrapper. 2. Provide getters and setters and make it thread-safe for folks who want multiple pools with almost identical configuration. 3. Drop the Factory entirely. Observations: DBCP2 doesn't need these factories. The factories aren't adding very much value. Conclusions: On reflection, I am leaning towards dropping these factories entirely. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
