[jira] [Resolved] (CONFIGURATION-542) Rework sychronization of configurations

["Oliver Heger (JIRA)" <ji...@apache.org>]

     [ 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