On 14/12/2011 17:27, sebb wrote: > On 14 December 2011 17:01, Mark Thomas <ma...@apache.org> wrote: >> 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. > > Yes, but 1.4 shows how factories have been historically used. > AFAIK, DBCP2 has yet to be used in the field. > >>> 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. > > Indeed. > >> Conclusions: >> On reflection, I am leaning towards dropping these factories entirely. > > I did wonder about that as well; in which case the interfaces can > presumably be dropped too. > > My preference order is: 3 or 1, else 2.
Assuming there are no objections I'll commit the removal of the factories and the interfaces some time tomorrow. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
