The work to make Commons Configuration thread safe is only in the latest version in trunk and so the documentation may not reflect that. We found that Combined Configurations were corrupted during reload and put in the effort to fix that. We never update the configurations in the application so I didn't test for thread safety between get and put. However, a get must work properly while a reload is occuring.
Ralph On Sep 29, 2010, at 5:49 AM, Siddhartha S wrote: > > > > >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
