Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 32968 invoked from network); 13 Feb 2009 12:55:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Feb 2009 12:55:39 -0000 Received: (qmail 44476 invoked by uid 500); 13 Feb 2009 12:55:37 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 44437 invoked by uid 500); 13 Feb 2009 12:55:37 -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 44426 invoked by uid 99); 13 Feb 2009 12:55:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Feb 2009 04:55:37 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of wmertens@cisco.com designates 144.254.15.119 as permitted sender) Received: from [144.254.15.119] (HELO av-tac-bru.cisco.com) (144.254.15.119) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Feb 2009 12:55:28 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1DCt8127784 for ; Fri, 13 Feb 2009 13:55:08 +0100 (CET) Received: from dhcp-peg3-cl31144-254-5-143.cisco.com (dhcp-peg3-cl31144-254-5-143.cisco.com [144.254.5.143]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1DCt7t10420 for ; Fri, 13 Feb 2009 13:55:07 +0100 (CET) Message-Id: From: Wout Mertens To: user@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: [user] Re: reserving resources in Couch Date: Fri, 13 Feb 2009 13:55:07 +0100 References: <7528BFCF-2533-4A6F-AE60-C6968E219F88@cisco.com> <19C1C5D0-DC35-4FB0-B582-D40E3F7AFA75@blit.com> <12E12F65-1E36-4BF6-A3D7-868002B13084@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 13, 2009, at 12:14 PM, Jan Lehnardt wrote: > On 13 Feb 2009, at 11:59, Wout Mertens wrote: > >> Can I count on this always being true for a single-node CouchDB? > Yup. >> What about a replicating CouchDB cloud where competing instances (A >> and B) connect to the same CouchDB? > Not sure how this scenario is different from the single-node CouchDB > instance. Me neither, is why I asked ;-) Ok so it's the same. >> And, just out of interest, what would be a good way to do this if >> you have competing instances connecting to different CouchDBs in a >> replicating cloud? I think you'd have to make replication a part of >> the reservation process, right? > > Say you have two nodes and you reserve resource X on node 1 > with client A and resource X on node 2 with client B. X on 1 and 2 > will have different revision ids. On replication, this creates a > conflict. > Automatic conflict resolution will pick one of the revisions and > save it > as the lastest revision. All nodes participating in replication will > pick > the same winning revision. The losing revision is stored as a previous > revision. So you are guaranteed that only one process effectively can > hold the lock after replication. Ok so if that happens you need to make sure your app knows that it can have its lock revoked by replication. Looks like forcing per-document masters like Paul proposes seems the way to go (but then you have to be careful about node outages). Ok, thanks for the info, I get it now! Wout.