Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Subject: Re: [configuration] tension between auto-loading and synchronization
To: Gary Gregory <garydgregory@gmail.com>,
 Commons Users List <user@commons.apache.org>
References: <b61921b7-8535-8f35-3d28-546b4be7f188@globalmentor.com>
 <dc4b346f-7cce-b095-5e83-0c62361417bd@oliver-heger.de>
 <CACZkXPxmZMuKVNRh8k+24Y0KEEFFNONpJKLvLreXX+rCJb4N5g@mail.gmail.com>
From: Garret Wilson <garret@globalmentor.com>
Organization: GlobalMentor, Inc.
Message-ID: <bc098547-3f9d-41b9-80df-780e4d18db5d@globalmentor.com>
Date: Sun, 27 Nov 2016 09:14:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <CACZkXPxmZMuKVNRh8k+24Y0KEEFFNONpJKLvLreXX+rCJb4N5g@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------E42865F97B61C3A12D8621B1"
archived-at: Sun, 27 Nov 2016 17:14:47 -0000

--------------E42865F97B61C3A12D8621B1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

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>
>


--------------E42865F97B61C3A12D8621B1--