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 occur. -Joan ----- Original Message ----- From: "Klaus Schroiff" <[email protected]> To: [email protected] 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 merge. Anyway ... I noticed the following link on the developer ML about the conflict management in BigCouch: http://atypical.net/archive/2014/04/17/understanding-race-induced-conflicts-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 ? Thanks Klaus
