From dev-return-3336-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri Mar 13 17:42:37 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 4357 invoked from network); 13 Mar 2009 17:42:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Mar 2009 17:42:36 -0000 Received: (qmail 78065 invoked by uid 500); 13 Mar 2009 17:42:35 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 78025 invoked by uid 500); 13 Mar 2009 17:42:35 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 78014 invoked by uid 99); 13 Mar 2009 17:42:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Mar 2009 10:42:35 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wout.mertens@gmail.com designates 209.85.219.174 as permitted sender) Received: from [209.85.219.174] (HELO mail-ew0-f174.google.com) (209.85.219.174) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Mar 2009 17:42:27 +0000 Received: by ewy22 with SMTP id 22so233084ewy.11 for ; Fri, 13 Mar 2009 10:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=fVIHvM8C/rU1XEjm3i+4jgXAIZLDH6X6eGVlEaJPIuE=; b=m2IwHpf76MHe6cRLG9PgyMan4sd0fbMI1Uxh1t/LL3bnfHWtrYo6vIj688boMesqnX N99lgaX3yxEiukgeBHB13cSll8fRQRmvODWW3xvZFWrNb0Yd00ov/sYFIsweq3f7Oxt4 f+tO58kvIJYSv3VWJ19h2pFRsOZDANaW/cCYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=lwmpierDs2UiUu5dtBvGHHgsomEfm8bbPvpH7QllDvvMkUFb9aT8mVPdsW5yzPmFcZ Zf6ygUWELViiPNIrf6c55mHSWRAirZndi1Yi0eGPErtCmFMxmwxFD85muVbRIFK132OT 43OFDt9tUQZme9Abhm5Zc4UQSgflkM06/dxpc= Received: by 10.216.29.210 with SMTP id i60mr859919wea.84.1236966126206; Fri, 13 Mar 2009 10:42:06 -0700 (PDT) Received: from dhcp-peg3-cl31144-254-5-156.cisco.com (dhcp-peg3-cl31144-254-5-156.cisco.com [144.254.5.156]) by mx.google.com with ESMTPS id 7sm3662122nfv.65.2009.03.13.10.42.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Mar 2009 10:42:04 -0700 (PDT) Message-Id: <0E7BBB9C-CEEC-4DEC-9BF4-8B3D420A9974@gmail.com> From: Wout Mertens To: dev@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Bulk Docs - 'remove changes so far' Functionality? Date: Fri, 13 Mar 2009 18:42:01 +0100 References: <49B8FD3F.4050706@timparkin.co.uk> <1E890AD0-6DCE-4E06-B227-AC61DF1E72BA@apache.org> <49B9882F.6050307@timparkin.co.uk> <49BA299D.6090606@timparkin.co.uk> <49BA2D42.7000004@timparkin.co.uk> <49BA77DF.6000405@timparkin.co.uk> <342590F1-BCEA-4FF0-A430-D8FF25E30C97@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Mar 13, 2009, at 5:47 PM, Chris Anderson wrote: > On Fri, Mar 13, 2009 at 9:41 AM, Wout Mertens > wrote: >> On Mar 13, 2009, at 4:12 PM, Tim Parkin wrote: >> >>> I think all bulk doc changes were written somewhere and then only >>> switched in once the last was successful.. so no locking. >> >> But then if a normal write comes in while the bulk doc is being >> processed, >> how did it know to fail that write/fail the bulk? >> > > CouchDB updates are serialized, so if a normal write comes in during a > bulk update, the normal write waits. Of course, all this is different > if the bulk update is spread across multiple nodes. Crossing that > bridge is part of the motivation for limiting the feature to skip > conflict checking. Again out of curiosity, how would the spreading work? The bulk write would go to ibrowse, which would then contact multiple couches and give each of them some work? Wout.