Automatic Annotation Locking Mechanism (for collaboration)

[philippotto]

When allowing other users to edit an annotation, we currently expect the users to coordinate so that they don't work concurrently on the same annotation (this would result in conflicts). Until #6495 and #6791 are tackled, this can lead to problematic behavior for volume data.

This issue suggests an automatic locking mechanism which enforces that users cannot cause conflicts. I imagine it somewhat like this:

• the back-end holds a mutex per annotation (or per tracing?) (simpler than per tracing)
• when a user A opens an annotation, the mutex is acquired automatically and kept alive via a heartbeat (only necessary when other users may edit the annotation; so, don't do it when not shared?)
• when another user B opens an annotation and the mutex acquisition fails, a message à la User X is currently editing the annotation. Only showing read-only mode.. The front-end switches to read-only mode then.
• the front-end retries the mutex acquisition (analoguous to the heartbeat) and if it succeeds a message à la You may now edit the annotation. Reload the page to do so. (necessary to get the newest changes).
• a mutex is automatically released once the heartbeat is not received anymore (thus, when closing an annotation, this will happen)

A downside of this approach is that a mutex can be lost when being offline temporarily. However, the chances for this are low and a potential data loss is somewhat understandable when being offline without saving first (will only happen when somebody else edits inbetween obviously).

---

Note that the watchForSaveConflicts needs to be adapted probably so that the wording and semantics make sense with the locking mechanism.