Yeah. I considered making input stream wrappers that automatically used the read lock, and then released it on close(). Not sure if I did not successfully or not - you are welcome to review.
Point being that locks are involved in resource access; so me may need to look out for deadlock. -- Jody Garnett On 6 August 2015 at 04:24, Niels Charlier <[email protected]> wrote: > Hi Jody, > > Makes sense. It looks to me like the PR does use the ResourceListener > rather than FileWatcher. > > Ideally, the resource.lock() should also be used to have a uniform API for > locking. > > Regards > Niels > > > On 05-08-15 19:53, Jody Garnett wrote: > >> 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
