Processing a change event must be possible without locking the JavaMonitoredEditor. Otherwise a change propagation may be running (which needs to lock the JavaMonitoredEditor), but since it is run within a build Job, it in turn waits for the resource change Job to finish, which cannot proceed as it waits for the lock acquired by the change propagation Job. This is a classical deadlock.
In fact, we have used locking to avoid that multiple change processing or change propagation processes / jobs are running at the same time, whereas it should be specifically used to avoid race conditions and ensure memory consistency. This PR reduces the synchronization to what is absolutely necessary.
Processing a change event must be possible without locking the
JavaMonitoredEditor. Otherwise a change propagation may be running (which needs to lock theJavaMonitoredEditor), but since it is run within a buildJob, it in turn waits for the resource changeJobto finish, which cannot proceed as it waits for the lock acquired by the change propagationJob. This is a classical deadlock.In fact, we have used locking to avoid that multiple change processing or change propagation processes / jobs are running at the same time, whereas it should be specifically used to avoid race conditions and ensure memory consistency. This PR reduces the synchronization to what is absolutely necessary.