Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <AANLkTikoyHr0gwBhMXjBhGiYqkTq1QU=sLQrQsZAQwqd@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>
Date: Wed, 17 Nov 2010 19:15:58 -0500
Message-ID: <AANLkTimsD-oF4+_mHami_2GT7CXf1ooAD_e3g_yXniay@mail.gmail.com>
Subject: Re: Write race conditions, working without _rev
From: Chad George <chad@mgproducts.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=e0cb4e385666aee0b7049548b1eb

--e0cb4e385666aee0b7049548b1eb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I've been wondering about this for a while, when two update requests for th=
e
same document come to couchdb nearly simultaneously what exactly happens?

Is it possible for both requests to get the same revision of the document t=
o
update or is there some mechanism to force the updates to occur in series?

- chad


On Wed, Nov 17, 2010 at 1:51 PM, Paul Davis <paul.joseph.davis@gmail.com>wr=
ote:

> On Wed, Nov 17, 2010 at 1:49 PM, Jan Lehnardt <jan@apache.org> wrote:
> >
> > On 17 Nov 2010, at 19:24, Paul Davis wrote:
> >
> >> On Wed, Nov 17, 2010 at 1:02 PM, rpkeane@gmail.com <rpkeane@gmail.com>
> wrote:
> >>>
> >>>
> >>> Sent from my HTC on the Now Network from Sprint!
> >>>
> >>> ----- Reply message -----
> >>> From: "Luciano Ramalho" <luciano@ramalho.org>
> >>> Date: Sat, Nov 6, 2010 15:52
> >>> Subject: Write race conditions, working without _rev
> >>> To: <user@couchdb.apache.org>
> >>>
> >>> On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis <
> paul.joseph.davis@gmail.com> wrote:
> >>>> In the second case, the second person to write the document wins,
> >>>> erasing any changes the first write's effects. The first writer will
> >>>> then be in a state where his view of the database will be
> >>>> inconsistent. The thing his, he can't know because without requiring=
 a
> >>>> _rev token he'll never get a notification of any sort of error.
> >>>
> >>> As I understand, the situation you describe above never happens in
> >>> practice with CouchDB. A second PUT to the same document _id will
> >>> always require the _rev attribute, so there's no way to overwrite a
> >>> previous update by accident. This is one of the best features of
> >>> CouchDB for document-oriented persistency.
> >>>
> >>>
> >>> --
> >>> Luciano Ramalho
> >>> programador repentista || stand-up programmer
> >>> Twitter: @luciano
> >>>
> >>
> >> That's true if you don't use _update handlers to hack around that part
> >> of CouchDB's design.
> >
> > Update handlers can't bypass the rev check, they only take the decision
> > closer to the database. With two concurrent update functions, one will
> > fail and one will win.
> >
> > Cheers
> > Jan
> > --
> >
> >
>
> Touch=E9. Jan is quite right, that two simultaneous _update handlers
> that try and write the incomming doc with the current doc's _rev tag
> could still fail. They just make the window smaller as they're closer
> to the db.
>
> Paul
>

--e0cb4e385666aee0b7049548b1eb--