Hi,
one limitation of the 1.x versions of [configuration] is the incomplete
support for concurrent access to Configuration objects. In version 2.0
we should try to improve this.
I have some ideas about this topic - not fully thought out - and would
like to start a discussion. Here they are (in no specific order):
- Thread-safety is not always required. Therefore, I would like to take
an approach similar to the JDK Collections framework: having basic,
unsynchronized configurations which can be turned into thread-safe ones.
- Many Configuration implementations are based on a hash map. Access to
their content could be made thread-safe by replacing the map by a
ConcurrentHashMap.
- For hierarchical configurations situation is more complex. Here we
will probably need something like a ReadWriteLock to protect their
content. (There could be different lock implementations including a
dummy one used by unsynchronized configurations).
- Reloading is a major problem; at least in the way it is implemented
now, it is very hard to get synchronization correct and efficient.
Therefore, I would like to use a different strategy here. One option
could be to not handle reloading in Configuration objects, but on an
additional layer which creates such objects.
- Other properties of configuration objects (e.g. the
throwExceptionOnMissing flag or the file name) must be taken into
account, too. In a typical use case those should not be accessed
frequently, so it is probably not an issue to always synchronize them or
make them volatile.
Looking forward to your input
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
