MVCC for concurrent user access and updates to document


Hi guys,

I have been having a read of MVCC within Couchbase db.

I have come to a point where I need to implement but am confused in regards to whether I should be using CAS or not to do the job?

Basically there could be a few users accessing the documents within couchbase and may need to update around the same time hence I believe I need to implement the versioning but just need pointing in the right direction.

Any help/advice would be great.



Has anybody delt with Revision History when working with a JSON document that defines a GUI

Hi TJ,

From what you’ve described, it does sound as though CAS could be useful.

Let’s say you’re writing a CMS for a news site. A news story breaks. Reporter A is on the scene: she writes it up and publishes it on the site.

The story develops and the editor sends reporter B to another location to get more information. Both reporter A and reporter B need to update the story as things unfold.

Here’s what you need to know:

  • Couchbase Server will only ever keep one copy of the news story document (see caveats below).
  • When reporter A saves her story, you can ask Couchbase to return a CAS value; e.g. 111.
  • Each time the document is touched, or written-to, the CAS value changes.
  • When reporter B saves his new version of the story the CAS will change; e.g. 222.
  • When reporter A makes a further revision, you’ll check to see if the CAS is still 111 but you’ll find it is 222.
  • This is where your knowledge of the business requirements comes in: in the case of a developing news story you probably want to save the latest version even if the CAS has changed. However, you might want to say that reporter updates can’t overwrite an update written by the editor. The CAS value won’t tell you if the update was made by an editor or a reporter but it will let you know that something has changed since your last update and then check whether your current user has permission to over-write the changes of whoever made the intervening change.

Let me know more about what you’re building and we can go into some more detail.

Caveats about the “one version” thing:

  • You could, of course, choose to build your systems such that you create a new document for each revision. You could that fairly easily by appending a version number, timestamp, or something similar to key name. That would be useful for preserving the history of your document, but not necessary for conflict resolution as Couchbase is strongly consistent within a cluster.

  • You might read that Couchbase Server uses an append-only disk storage format but the historic versions of a document are not available to you, the developer, and they are frequently compacted anyway.

  • Couchbase Mobile is another matter, as it’ll provide you with a tree of changes CouchbDB-style; conflict resolution being necessary where there are unreliable mobile network connections etc.