Locking
Cloud CMS locking is a "data lock" approach which is a transactional lock is taken out when the write of multiple documents begins. This is a transactional lock in the sense that it blocks other write operations against those documents and fails entirely with rollback if any of the documents fail individually.
We have transactional writes for multiple documents. We have a changeset-driven versioning model where each transaction writes onto it's own changeset. N number of documents may write at the same time and in the same transaction. If anything fails, the whole thing rolls back and so forth. In fact, every write operation to a Cloud CMS branch is always transactional - all the way down to the MongoDB layer.
However, the downside of this approach is that it is possible for two users on two different machines within our user interface to bring up a form for the same document. If both users click "save" at the same time, two requests will be sent to the API to save. The first one will claim the branch write lock. The second will see the branch write lock is claimed and wait. The first will then complete, saving its changes. It then releases the branch write lock. The second thread wakes up and now claims the branch write lock. It writes and then releases the branch write lock.
As a result, the first user's changes are overwritten by the second user. This can introduce some confusion if the first user doesn't see their changes. They have no way of knowing that the second user was editing at the same time.
Some systems solve this by having the second user receive an error which indicates that the version currently saved is more recent than the one they started editing. The user then has to reload and re-enter their values. Which, in my experience, is sometimes even more frustrating.
Another solution is to provide an indication that someone else is editing the document. Or perhaps not allow the second user to open the form is the first user already opened the form.
All of these solutions involve having a "UI lock" approach. At the moment, Cloud CMS does not have this. We've gone the route at the moment of supporting "last write wins".
Manual Document Lock/Unlock
We also offer per-document locking. This is less sophisticated than the UI or data-level locking discussed above. It basically is an intentional lock that an editor can request. Once the lock is taken out, write operations against the node are blocked unless the current user performing the operation owns the lock.
This lock is useful because it provides a way for editors to signal that they're working on something. By taking out that lock, other editors will see that the document is locked ahead of beginning any work. Effectively, this lock could play a role in terms of implementing a UI lock.
To lock a Document, click "lock" on the Document Overview page in the Document Actions section
