Am 28.09.2010 22:19, schrieb Siddhartha S:
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.
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
) 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]
