From user-return-13782-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Nov 17 18:52:12 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 91749 invoked from network); 17 Nov 2010 18:52:11 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 Nov 2010 18:52:11 -0000 Received: (qmail 81694 invoked by uid 500); 17 Nov 2010 18:52:41 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 81659 invoked by uid 500); 17 Nov 2010 18:52:41 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 81651 invoked by uid 99); 17 Nov 2010 18:52:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Nov 2010 18:52:41 +0000 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.214.180 as permitted sender) Received: from [209.85.214.180] (HELO mail-iw0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Nov 2010 18:52:36 +0000 Received: by iwn37 with SMTP id 37so2483743iwn.11 for ; Wed, 17 Nov 2010 10:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=r75Sp68NjWaNttknGHg952VUEaKXagAmPuFxK+CtLwI=; b=Fma3qggTOmeQFAzRXNXiOEu2SP71sAKPw5VBFYg29kXjyPOYOgFeDGeiEAmEH2XTGX 629RnEhkdT+hrwqpN8QoE7jwwhyMqrJngDa9nkStWLvDmxISXaYM5glx1V7z7L8XaTov RIhsADHpq+OnPH3KB2DjKkXSmPOnrWNvcr1QY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=fnU6lMAaFwTBJmkkMqPaKNxdgBVF1gnz10eAhav1KI2V31VTS2kwiVgOVbzoRo7tgM YWKwYqL2SI+oapP7Cm29+1I23IamkrABFFEV2ZdrTu4EsuWasgYWCNb39pCLIWC0WFLI Rm86UghEXbPSB3EB63svy5nx06mElju59zcyI= Received: by 10.231.39.137 with SMTP id g9mr7340339ibe.101.1290019935017; Wed, 17 Nov 2010 10:52:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.35.5 with HTTP; Wed, 17 Nov 2010 10:51:34 -0800 (PST) In-Reply-To: <23543823-7536-4620-AB61-A3AC8BAA43B8@apache.org> References: <4ce418b2.096ee60a.57dd.7e17@mx.google.com> <23543823-7536-4620-AB61-A3AC8BAA43B8@apache.org> From: Paul Davis Date: Wed, 17 Nov 2010 13:51:34 -0500 Message-ID: Subject: Re: Write race conditions, working without _rev To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2010 at 1:49 PM, Jan Lehnardt wrote: > > On 17 Nov 2010, at 19:24, Paul Davis wrote: > >> On Wed, Nov 17, 2010 at 1:02 PM, rpkeane@gmail.com w= rote: >>> >>> >>> Sent from my HTC on the Now Network from Sprint! >>> >>> ----- Reply message ----- >>> From: "Luciano Ramalho" >>> Date: Sat, Nov 6, 2010 15:52 >>> Subject: Write race conditions, working without _rev >>> To: >>> >>> On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis 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