User-controlled locking can coexist with locking for short transactions. While a user is writing a (long) node, the ongoing work will be saved frequently so as to not lose a lot of information in the (unlikely?) event of a system crash. Meanwhile the user wishes to keep the node locked for the entire duration of the editing session.
Shared Locking
Allowing locked objects to be read enables users to navigate through a
hyperdocument containing locked objects.
The only conflicts we wish to avoid are write-write conflicts.
Being able to read the ongoing work of other writers can be helpful,
for instance to view how one writer has defined a term another writer
wishes to use.
Fine-grained Locking
Databases typically provide locking at the object level (or worse).
Locking at the attribute level reduces the risk of conflicts.
While one writer is adding text to a node another writer may wish to
turn a word in another part of the same node into a link anchor.
Since fine-grained locks may be held for only a short time (there's only so much updating one can do on a small part of an object) one may consider queuing lock requests instead of denying them.
Persistent Locking
Locks should be stored on both the client and the server side.
When a server goes down and recovers,
the clients should be able to reclaim the locks they had before the crash.
When a client is restarted after a crash it should be able to retrieve
the locks from the server.