commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garret Wilson <>
Subject [configuration] tension between auto-loading and synchronization
Date Fri, 25 Nov 2016 21:55:02 GMT
I'm reading the documentation for the new commons-configuration 2.x. I 
have a simple need: load a configuration file from a properties file, 
reload it when the file changes, and make the configuration thread-safe 
for reading.

 From the documentation I understand that I shouldn't keep the 
Configuration object around, because it may be reloaded if the file 
changes. Instead I should keep a ConfigurationBuilder around. So my 
application's getConfiguration() would look like this:

public Configuration getConfiguration() {
   return configurationBuilder.getConfiguration();

But I need it to be thread-safe. So I do this:

public Configuration getConfiguration() {
   Configuration configuration=configurationBuilder.getConfiguration();
   configuration.setSynchronizer(new ReadWriteSynchronizer());
   return configuration;

Oops! It turns out that we don't know if the builder returns the same 
configuration or a new configuration, so we could be swapping out the 
synchronizer on the same configuration. That introduces a race condition 
and defeats the thread safety!

So are we expected to keep a separate synchronizer around and make sure 
the new/existing configuration uses it?

private final Synchronizer synchronizer = new ReadWriteSynchronizer();

public Configuration getConfiguration() {
   Configuration configuration=configurationBuilder.getConfiguration();
   return configuration;

Wow, that's getting complicated. The problem is that Apache Commons 
Configuration2 recommends that the builder be the ultimate source of the 
configuration, yet it associates the syncrhonizer with the actual 
configuration instance. Shouldn't we set the synchronizer on the builder 
and let it manage the synchronizer of the new configurations? Or do you 
want each configuration to potentially have different synchronizers? But 
is that realistic---would synchronized and unsynchronized configurations 
play well together if they are backed by the same builder? I'm trying to 
understand what the expected usage is.


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

View raw message