commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] tension between auto-loading and synchronization
Date Mon, 28 Nov 2016 21:13:22 GMT


Am 27.11.2016 um 18:14 schrieb Garret Wilson:
> Thanks for clearing this up, Oliver!
> 
> I was going straight from the documentation. On the page
> https://commons.apache.org/proper/commons-configuration/userguide/howto_concurrency.html
> I can't find anything about setting up the builder parameters.
> 
> So I'm extremely happy to learn that you can configure the builder with
> a synchronizer. So I guess the "tension" now is that part of the
> documentation says, "it's better to use a builder than the configuration
> itself, especially if you want auto-loading", and then the part that
> actually talks about synchronization seems to favor working with the
> configuration and doesn't even mention that I can set the synchronizer
> on the builder.
> 
> At the very least
> https://commons.apache.org/proper/commons-configuration/userguide/howto_concurrency.html
> should mention the configuration params.

I will try to make it clearer.

Oliver

> 
> Cheers,
> 
> Garret
> 
> 
> On 11/27/2016 8:58 AM, Gary Gregory wrote:
>>
>> Do we need better Javadocs to make this obvious?
>>
>> Gary
>>
>>
>> On Nov 27, 2016 7:02 AM, "Oliver Heger" <oliver.heger@oliver-heger.de
>> <mailto:oliver.heger@oliver-heger.de>> wrote:
>>
>>     Hi,
>>
>>     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>(
>>                     PropertiesConfiguration.class)
>>                     .configure(params.basic()
>>                             .setSynchronizer(sync));
>>
>>     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.
>>
>>     Oliver
>>
>>
>>         Garret
>>
>>        
>> ---------------------------------------------------------------------
>>         To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>         <mailto:user-unsubscribe@commons.apache.org>
>>         For additional commands, e-mail: user-help@commons.apache.org
>>         <mailto:user-help@commons.apache.org>
>>
>>
>>     ---------------------------------------------------------------------
>>     To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>     <mailto:user-unsubscribe@commons.apache.org>
>>     For additional commands, e-mail: user-help@commons.apache.org
>>     <mailto:user-help@commons.apache.org>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message