[ 
https://issues.apache.org/jira/browse/CONFIGURATION-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-542.
----------------------------------------

    Resolution: Fixed

Synchronization of configuration objects has been rewritten: A so-called 
{{Synchronizer}} is now used to control concurrent access to a configuration. 
While the default synchronizer is just a dummy, applications can change it 
according to their use cases. There is also an implementation of 
{{Synchronizer}} based on the JDK's {{ReentrantReadWriteLock}} class.

All Configuration implementations have been adapted (the major part of the 
functionality required could already be implemented in base classes). The 
drawback of this approach is that there are now lots of interactions with 
{{Synchronizer}} objects all over the code. This is probably an unavoidable 
side-effect when using locks to protect shared data. So it is easy to miss a 
place.
                
> Rework sychronization of configurations
> ---------------------------------------
>
>                 Key: CONFIGURATION-542
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-542
>             Project: Commons Configuration
>          Issue Type: Improvement
>            Reporter: Oliver Heger
>             Fix For: 2.0
>
>
> In the original approach configuration objects were not thread-safe. In later 
> versions, more and more synchronization was added to support concurrent 
> access to configuration properties, even when reloads occurred.
> Unfortunately, the current implementation is not very clean and has a lot of 
> problems. There a several bug reports related to this topic. Therefore, 
> version 2.0 which will break backwards compatibility is a good opportunity to 
> introduce a new concept for synchronization.
> Of course, the new approach should be easier, cleaner, and customizable. I 
> would also like to have an option to avoid synchronization completely if this 
> is not required for a specific use case. Maybe a similar pattern as used by 
> the Java collections framework can be applied: per default, configurations 
> are not thread-safe, but there is an option to add synchronization so that 
> they can be accessed concurrently.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to