commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject [configuration] Thoughts about multi-threading
Date Sat, 15 Sep 2012 15:52:50 GMT

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 

- 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

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

View raw message