Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.200.173 as permitted sender)
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=YXBk0yfrfDtPjYwnn75ofmdHo8NoReroWBDH55t3+/HSALqIJi2F/7A9nBSduqEkEE
         UfrbmWOfciwdrLl3U4MB5PCf2AHq6lNesNDAcpOZzfuOxtxLIhH+/70tG2/28RJI9zmj
         IQ1zf5JDj1M9HbyYsLyRVy8pK6tvurFqckWjU=
Message-Id: <78405882-D014-474A-9DB9-3900BA769051@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>
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 10:01:26 +1030
References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>


On 08/02/2009, at 2:17 AM, Damien Katz wrote:

> 1. Transactions don't work with replication. Replication doesn't  
> repeat the bulk single transaction, it just copies the documents  
> individually to the target replica. This means any downstream  
> replica can and will sees inconsistent states until replication  
> fully completes, not "all or nothing" states. With bidirectional  
> replication is even worse, as you can get edit conflicts that must  
> be resolved by an external process, .

This presumes that the UI model doesn't distinguish between conflicts  
due to replication and constraint failures due to local ACID operations.

In my Notes Client-like model for example:

1. Web actions such as form submits don't result in conflict - they  
either succeed or fail, to be retried. Users don't want to be thrown  
into a conflict resolution UI when they hit save on a document that  
they've been editing for some time.

2. Replication and normal operation are exclusive states. The  
replication process checks for conflicts, and won't re-enter the  
normal operational state until conflicts are resolved by the user,  
using a specialized replication-conflict UI.

In my model, conflicts only ever occur due to replication, and this  
fact allows applications to be considerable simpler, and the user  
experience to be IMO vastly superior.

> 2. Transactions don't work in a partitioned database without a huge  
> performance hit (locking + 2 phase commits).

Can you share your thinking about your model for a partitioned  
database? For example: are there any consistency guarantees or ACID  
constraints (e.g. storage) within the cluster? Is there actual or  
effective serialization of updates on a cluster-wide basis? Are views  
cluster-wide?

I really need to know more about your model before I can reason about  
this point.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Success is not the key to happiness. Happiness is the key to success.
  -- Albert Schweitzer