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();
configuration.setSynchronizer(synchronizer);
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.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
