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:
- Event notification. Users need to be notified of changes
made to objects by other users.
- 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.
- 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.
- Shared locking. Locked objects must always remain readable,
so users can get a common view of the information space.
- 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.
- 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].