Concurrency Issues with Collaborative Authoring

In order to avoid consistency problems (and confusion) when multiple authors work on the same hyperdocument, a hypertext system should offer several levels of concurrency control:
  1. Event notification. Users need to be notified of changes made to objects by other users.
  2. Fine-grained notification. The event handler must be able to distinguish between write operations on the data field (content) and on other attributes of nodes.
  3. User-controlled locking. In addition to implicit locking within the scope and control of transactions, users must be able to lock objects during a long update that outlasts several short transactions.
  4. Shared locking. Locked objects must always remain readable, so users can get a common view of the information space.
  5. Fine-grained locking. While one user is updating the data field (content) of a node, other users should still be able to annotate or create new attributes in the node.
  6. Persistent collaboration information. Locks, events, and other information about the collaboration between users must not only be stored in a server process. Clients need to be able to recover from server crashes and therefore need to have persistent collaboration information.
There is more detailed information on locking, notification, transactions and versions. This is mostly taken from [KWL93].