On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> 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? This would simplify the classes by eliminating all the setters, and should make consistency checking easier. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
