> 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: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
