From dev-return-2334-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sat Feb 07 23:26:26 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 65275 invoked from network); 7 Feb 2009 23:26:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2009 23:26:26 -0000 Received: (qmail 84190 invoked by uid 500); 7 Feb 2009 23:26:25 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 84155 invoked by uid 500); 7 Feb 2009 23:26:25 -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 84144 invoked by uid 99); 7 Feb 2009 23:26:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Feb 2009 15:26:25 -0800 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 antony.blakey@gmail.com designates 209.85.200.175 as permitted sender) Received: from [209.85.200.175] (HELO wf-out-1314.google.com) (209.85.200.175) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Feb 2009 23:26:17 +0000 Received: by wf-out-1314.google.com with SMTP id 28so1456349wff.29 for ; Sat, 07 Feb 2009 15:25:57 -0800 (PST) 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=1OBhWCLDCut/AwbXoL6FINBOD1KGtvZ/D7ZoU4ECc30=; b=KCK4WFRY3rHneuVFXonUMF87XcqiFDTFktoovkGWjeW3bevhkoJrhRGU9vtTnqaUpf zUAPjhkBh4yCvLFsIWm2jWa/mDV2ZocSczTUI8tPfRiSRsZeL7XW5zW75UP8WLWfmjSX yZBa4+N6ySda+KkIjKHiVRvL5dKkEenYUhODI= 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=XOX4Eo8aFaZ4KpSQRk3piKX/l7DnNuc5SrXmmforxj/RV62eWPxctezB/rNzvNogAl MmtdbhE8zA2gpekiyauDdDEekapLcURWn3SYX53UpPeQM/X+vrS5NaIIdaaAeUutOCmp nnKo/Y79nqg1ASkGaoUKSWVeT2RwDINAsloLo= Received: by 10.142.144.16 with SMTP id r16mr1907347wfd.240.1234049156963; Sat, 07 Feb 2009 15:25:56 -0800 (PST) Received: from ?192.168.0.16? (ppp121-45-202-232.lns10.adl2.internode.on.net [121.45.202.232]) by mx.google.com with ESMTPS id 30sm6904002wfd.35.2009.02.07.15.25.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Feb 2009 15:25:56 -0800 (PST) Message-Id: From: Antony Blakey 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: couchdb transactions changes Date: Sun, 8 Feb 2009 09:55:52 +1030 References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com> <3B1EB33E-D224-43E2-9FDC-D7493CD5BFDD@pobox.com> <59473D22-6EA5-4CE2-A193-8F4938C2D6BB@apache.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On 08/02/2009, at 4:53 AM, Chris Anderson wrote: > On Sat, Feb 7, 2009 at 8:22 AM, Damien Katz wrote: >> >> On Feb 7, 2009, at 11:02 AM, Geir Magnusson Jr. wrote: >> >>> Thanks for the info. Is there a third mode possible? Namely all or >>> nothing with conflict check, with the understanimg that the >>> conflict >>> guarantee is only at commit, and all bets are off after that when >>> replicated? >>> >> >> That's what we currently have. It's possible to keep supporting it, >> but it >> doesn't work with any of CouchDB's distributed features. It's only >> appropriate for a single node instance, even a hot standby slave >> will have >> inconsistent states. >> > > I'm asking this with my computer science hat off. Is there room for > someone to implement the current behavior on top of a partitioned > cluster, by using a consensus-algorithm based transaction manager? I'm fairly sure that doing this transparently isn't feasible. Consider the case of a transaction where one update succeeds and one fails. The database is now inconsistent wrt. expected transactional semantics. The time between the initiator of the transaction seeing the conflict and taking remedial action is unbounded. In the meantime a concurrent operation sees this inconsistent state. More succinctly, it seems to me that Isolation isn't without the imposition of an explicit serialization mechanism for writes that requires a one-write/no-reader exclusion model. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen