On Dec 14, 2011, at 14:12, sebb <[email protected]> wrote: > On 14 December 2011 18:29, Mark Thomas <[email protected]> wrote: >> On 14/12/2011 12:10, sebb wrote: >>> This is a parallel thread to the one about PoolFactory implementations. >>> >>> I'm trying to establish the mutability needs of the >>> [Keyed]ObjectPool implementations, i.e. >>> >>> Generic[Keyed]ObjectPool >>> >>> I've looked at DBCP 1.4, which uses POOL 1.x. >>> >>> SharedPoolDataSource.registerPool() creates an instance of >>> GenericKeyedObjectPool which it configures via the setters; however >>> the instance is then stored in a KeyedObjectPool, and setters/getters >>> are not used elsewwhere. >>> >>> SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance >>> of GenericKeyedObjectPool which is then only used via the >>> KeyedObjectPool interface. >>> >>> So: as far as I can tell from DBCP, there is no need to provide >>> mutable ObjectPool implementations; so long as the pool can be >>> configured intially, that is sufficient. >>> >>> Are there any other existing use cases that I am missing here? >> >> I do see periodic requests to be able to change the (DBCP) pool >> properties dynamically and it was my intention to support this use case >> via JMX for POOL2. > > Ah - that is a new requirement. > >> JNDI assumes resources are essentially beans i.e. have zero argument >> constructors and getters/setters. If this is not the case then some >> extra plumbing is required. The further G[K]OP gets from a JavaBean the >> more plumbing required. Currently the only extra plumbing required is to >> work-around the zero-argument constructor. Removing the setters would >> mean more plumbing would be required for someone to create a custom JNDI >> resource for a pool of objects of type X. > > But AFAIK JNDI does not allow dynamic changes, so can operate on the > config classes - which do have the required characteristics, AFAICT. > >> DBCP already has the plumbing to handle the removal of the setters but >> it would require some code changes. > > I committed a fix earlier today which changed the one remaining class > that used setters on the pool so it now uses setters on the config > class. > The other pool creation classes already did that. > AFAICT, DBCP2 does not need to use setters on the pool at present. > >> It was always my intention to provide the ability to change the pool >> properties on the fly. I would rather spend a little time fixing the >> remaining threading issues than drop that requirement. I certainly don't >> want to try coding DBCP to support dynamic changes when the underlying >> pool does not. > > That is a new requirement on DBCP (of which I was previously unaware) > - and does of course change things. > >> Given that there is a requirement from DBCP users for dynamic changes to >> the pool, I believe POOL2 needs to support mutable pool implementations. > > The more mutable fields there are, the more work to be done to ensure > thread-safety, and the more checking/unit tests needed when updating > the code. > > So - are there any settings that it does not make sense to mutate > after creation? > > For example, LIFO? > jmxEnabled/jmxNamePrefix? > testOnBorrow/testOnReturn/testWhileIdle? > blockWhenExhausted? > > And are there settings which need to be constrained relative to other > settings? > For example some of the counts probably have inter-dependent ranges. > If so, then where is the validation going to be done? > > Would it make sense to only allow changes via the config class?
I should then be able to get a config object from a pool, tweak it, and pass it back. Gary > > This would simplify the classes by eliminating all the setters, and > should make consistency checking easier. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
