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