Jukka Zitting wrote:
Do we have some directions that seem worth pursuing? Would rethinking
the locking mechanisms be enough, or do we need to fundamentally
modify the basic ItemStateManager and VersionManager designs?
I haven't thought about this in much detail, but IMO the sequence how locks are
acquired is the most problematic part of this issue. If we can ensure that locks
are always acquired in the same sequence a deadlock shouldn't occur that easily.
Here's what I've been thinking about:
- Add a check to the SharedItemStateManager (SISM) if it has
VirtualItemStateProvider (VISP). This will be the case for the workspace SISM,
but not for the SISM in the version manager. Furthermore if the change log
contains references into one of the VISPs, those VISPs must be write locked
*before* this SISM is write locked. Otherwise only this SISM needs to be locked.
This should ensure that the lock sequence is always: VISP and then SISM.
I'm not sure about the lock in AbstractVersionManager (AVM), but since the AVM
is on a higher layer than the VISP the overall lock sequence should be: AVM,
VISP then SISM.
Thoughts?
regards
marcel
