commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] tension between auto-loading and synchronization
Date Sun, 27 Nov 2016 15:02:09 GMT

Am 25.11.2016 um 22:55 schrieb Garret Wilson:
> 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.

you configure the builder to set the correct synchronizer on newly 
created Configuration objects. To achieve this, call the builder's 
configure() method with a parameters object. Focused on the 
synchronizer, this looks as follows:

Synchronizer sync = ...;
Parameters params = new Parameters();
BasicConfigurationBuilder<PropertiesConfiguration> builder =
         new BasicConfigurationBuilder<PropertiesConfiguration>(

Just insert your type parameters for the configuration type. All 
properties configured this way are automatically set on the 
Configuration each time a new instance is created.


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

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

View raw message