incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: BigCouch merge - conflict management
Date Thu, 24 Apr 2014 02:42:16 GMT
Hi Klaus,

I'm the one who wrote that post.

The answer is that BigCouch *does* pick a winner, but it does *not* clean up the conflicts.
The choice made, just like Apache CouchDB today, is arbitrary - and if that's good enough
for you, then you can just let that one win. That is what MVCC is, and what it does.

Without having a "write master" in a cluster - a single writer in a cluster that locks for
each document - or something like special hardware GPS-linked clocks and pre-measured timing
between nodes to help build a vector clock tree (as Google does internally), it is not possible
to achieve the behaviour you are looking for by definition. 

A write master means that you are picking Consistency over Availability in the CAP theorem.
If you want CP instead of AP, there are other systems that provide this option - MongoDB,
Redis, MemcacheDB, BerkeleyDB, HBase, etc. CouchDB, even in the single node approach with
replication to other nodes via HTTP without the BigCouch piece, is AP. BigCouch simply "speeds
up" that conflict process, rather than waiting for when you trigger replication to make that


----- Original Message -----
From: "Klaus Schroiff" <>
Sent: Wednesday, April 23, 2014 7:40:49 PM
Subject: BigCouch merge - conflict management

Hi all,

I am "just" a user so I'm not sure where to post this because the following is about the BigCouch
Anyway ... I noticed the following link on the developer ML about the conflict management
in BigCouch:

Compared to other NoSQLs, it is at least, in my opinion, a godsend value prop of (non-Big-)CouchDB
that it provides immediate feedback upon a document collision via MVCC.
You either win or lose unless you deal with replication where we have to live with more complex
conflict resolution.
With the BigCouch merge things seems to be getting more fuzzy here.  Or to phrase it differently
- BigCouch is not drop-in compatible when relying on this mechanism.

Now I understand the reasoning behind all this but is this what we really want ?

Of course, we could alter our code as mentioned in the doc above but this appears to be a
workaround rather than a solution. And it costs performance.
I feel that it would make at least sense to have a configuration parameter where BigCouch
"simply declares a winner" rather than leaving it to the (multiple) clients to clean up the
doc revisions somehow.
In my view there should be a higher strictness of the replica handling within the cluster
compared to external replication.
Just accepting the consequences by pointing to "eventually consistency" is a bit weak IMHO.
>From my viewpoint CouchDB has two key differentiators - MVCC and replication - and MVCC
is getting less powerful then.

Thoughts ?



View raw message