couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 01:19:20 GMT

On Feb 7, 2009, at 6:31 PM, Antony Blakey wrote:

> 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.

We will still have the same support for interactive conflict detection  
for single document updates. That's relatively easy to do with  
partitioned databases and definitely part of the plan.

>> 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?

No interdocument consistency guarantees. Views are 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

View raw message