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