Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of mikefedyk@gmail.com
 designates 74.125.82.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=WzzGF8XQkL1aIEt3nGPpevn9ZZU6OZZq5PKN+/bSXOpc5eKnB9l89ONSWv97yUISZF
         cAsM2Oz+TQ/G+/GRRmF9/V23FRVB3immRXaxzqjTMKukCoYnLtv70popE1/tpYZ7u4U1
         f5pwZ/Ddo1GUEUtVuNKtmiYLAbakigp/bcYHk=
MIME-Version: 1.0
Sender: mikefedyk@gmail.com
In-Reply-To: <AANLkTi=jP=1GcR7PeE-bWOZmxLH6Xn2rJ9DG_BvCrYTD@mail.gmail.com>
References: <4ce418b2.096ee60a.57dd.7e17@mx.google.com>
	<AANLkTimxCHoSz5tBgDTp1E0EQT2u0jLBDXtKdJ5mzozV@mail.gmail.com>
	<23543823-7536-4620-AB61-A3AC8BAA43B8@apache.org>
	<AANLkTikoyHr0gwBhMXjBhGiYqkTq1QU=sLQrQsZAQwqd@mail.gmail.com>
	<AANLkTimsD-oF4+_mHami_2GT7CXf1ooAD_e3g_yXniay@mail.gmail.com>
	<AANLkTi=jP=1GcR7PeE-bWOZmxLH6Xn2rJ9DG_BvCrYTD@mail.gmail.com>
Date: Wed, 17 Nov 2010 17:53:21 -0800
Message-ID: <AANLkTi=3wr_S7y0C0tOHRH20HthvKDHGOK4RNWefXW+T@mail.gmail.com>
Subject: Re: Write race conditions, working without _rev
From: Mike Fedyk <mfedyk@mikefedyk.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 17, 2010 at 5:14 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Wed, Nov 17, 2010 at 16:15, Chad George <chad@mgproducts.com> wrote:
>> I've been wondering about this for a while, when two update requests for the
>> same document come to couchdb nearly simultaneously what exactly happens?
>>
>> Is it possible for both requests to get the same revision of the document to
>> update or is there some mechanism to force the updates to occur in series?
>>
>
> There is a mechanism. The message passing within the Erlang runtime
> guarantee an ordering of messages to the update process.
> It is impossible for both updates to occur.
>

I imagine that first in the queue wins in one instance of couchdb, but
that doesn't tell the whole picture with two writes each on a separate
instance of couchdb.  At least the docs say that the sort order of the
revs (including the md5 of the document), so whichever wins the sort
will be the latest _rev.

You want to design your apps to have as few write conflicts as
possible, but you still need to be able to handle them when they do
happen.