commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [commons-configuration] About reloading and thread-safety
Date Wed, 29 Sep 2010 13:35:55 GMT
The work to make Commons Configuration thread safe is only in the latest version in trunk and
so the documentation may not reflect that.  We found that Combined Configurations were corrupted
during reload and put in the effort to fix that. We never update the configurations in the
application so I didn't test for thread safety between get and put. However, a get must work
properly while a reload is occuring.

Ralph

On Sep 29, 2010, at 5:49 AM, Siddhartha S wrote:

> 
> 
> 
> 
>> Hi,
>> 
>>> Thank you for your response. An additional question :
>>> 
>>> "The lock you mention is just for protecting reload operations (i.e. if
>>> the file on disk has changed). There is no protection against concurrent
>>> updates by multiple threads. "
>>> 
>>> Are there examples in documentation/code that illustrate this? The 
> addProperty
>>> method, for example, appears to have a synchronized block. Is it still unsafe

>>> to
>>> use this method across multiple threads without (explicit, additional)
>>> serialization? What am I missing?
> 
>> The getProperty() methods are not synchronized. Therefore it is not safe 
>> to update a configuration in one thread while other threads may read data.
> 
> 
> The getProperty method appears to be synchronized using the same reloadLock as 
> per the source here : 
> http://svn.apache.org/repos/asf/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
> . How is it that reloading from a different thread is thread-safe but not 
> writes (given that addProperty also appears to synchronize using the same lock). 
> The reasons are not clear from the source/documentation.
> 
> Thanks,
> -Sidharta
> 
> 
> 
> 
> 
> 
> Oliver
> 
>> 
>> thanks,
>> -Sidharta S
>> 
>> 
>> 
>> 
>>> As per documentation, most of the concrete implementations of the
>> Configuration
>>> interface are not thread-safe when modifications are involved. However,
>> looking
>>> at AbstractFileConfiguration (
>>> http://svn.apache.org/repos/asf/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
>>> a
>>> a
>>>   ) and
>>> (http://svn.apache.org/repos/asf/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java)
>>> )
>>> )
>>>   , it appears that access *is* synchronized through a reload lock. Do the
>>> concrete implementations (e.g XMLConfiguration) do something that makes them
>>> non
>>> thread-safe with respect to reloads?
>> 
>> The lock you mention is just for protecting reload operations (i.e. if
>> the file on disk has changed). There is no protection against concurrent
>> updates by multiple threads. This is in the responsibility of the developer.
>> 
>> Oliver
>> 
>>> 
>>> 
>>> thanks,
>>> -Sidharta S
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: 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