commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
Date Wed, 14 Dec 2011 22:22:41 GMT
On 14/12/2011 19:12, sebb wrote:
> On 14 December 2011 18:29, Mark Thomas <> wrote:
>> 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.

Which is what I mean by "more plumbing". Given that DBCP users want to
change pool config on the fly, I imagine users of other pools will to.

>> 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?
May as well be mutable.

> jmxEnabled/jmxNamePrefix?
That can / should be fixed.

> testOnBorrow/testOnReturn/testWhileIdle?

> blockWhenExhausted?

> And are there settings which need to be constrained relative to other settings?
No. We don't do this currently and I don't see a need to start. There
are some combinations that don't make much sense but we don't enforce

> Would it make sense to only allow changes via the config class?
No. The config class can be a short-cut but I don't think it is the only
way. Note that changes via a config class won't be atomic unless we make
some changes.

> This would simplify the classes by eliminating all the setters, and
> should make consistency checking easier.
I don't think we need consistency checking.

My current thinking is:
- make all mutable attributes volatile
- methods take local copies of the attributes they require at the start
of the method to ensure consistency


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message