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. > Mark > > --------------------------------------------------------------------- > 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
