commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siddhartha S <s_siddharth_re...@yahoo.com>
Subject Re: [commons-configuration] About reloading and thread-safety
Date Wed, 29 Sep 2010 12:49:04 GMT




> 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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message