Quick question Niels since we were discussing Resource and LockProvider the other day.
I am reviewing the goal_translate pull request, which uses a watcher to monitor a Resource for changes. Inside the code there is a read/write lock to protect access during a resource change event. The watcher is just a short cut for looking out for resource changed events. I was wondering if the resource lock method should be used instead - the logic being that the LockProvider is configured under admin control and may be correctly configured for resource change events. I expect the pull request is fine as written, we will need to carefully consider what order to apply event notification, resource.lock(), and code monitors or read/write locks to prevent deadlock in a clustered environment. It would be good to highlight the use of a watcher like this, and see if it should migrate to direct ResourceListener use and if a Resource lock can be used. My rough idea is: 1. resource lock when writing the change 2. resource lock release when the event change is complete, followed by event notification to nodes in the cluster 3. resource listeners (including any file watchers) are notified and read the contents. If they have an internal read/write lock on the resulting data structure it should not introduce deadlock Key to the above being successful is ensuring that code such as dal_translate does not both hold a resource lock and their data structure read/write lock at the same time. Let me know if the above makes sense and we can highlight it in the developers guide. -- Jody Garnett
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
