On 14/12/2011 19:12, sebb wrote: > On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> 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? Mutable. > blockWhenExhausted? Mutable. > 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 anything. > 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 Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
