incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Trouble with replication
Date Fri, 30 Jan 2009 05:21:07 GMT

On 30/01/2009, at 9:45 AM, Jan Lehnardt wrote:

>
> On 30 Jan 2009, at 00:12, Antony Blakey wrote:
>>>
>>> It's not a conflict, the edit document is simply refused by B. The  
>>> replication of the remaining documents will continue.
>>>
>>> If a user on B also edits the document and it replicates to A,  
>>> then users of A will see a conflict, but users on B will not.
>>
>> So replication doesn't necessarily result in consistent state  
>> between nodes, with the further result that p2p meshes need to be  
>> aware of this because homogeneity of the mesh would depend on  
>> maintaining a consistent global order of updates, which isn't  
>> possible.
>>
>> Does this mean that this statement on the wiki overview: 'When  
>> distributed edit conflicts occur, every database replica sees the  
>> same winning revision' is no longer true?
>
> Modulo validation & access control, the statement is still true.

So the wiki statement should be qualified, because if validation and  
access control are widely used, then it's more like than not to be not  
true. It's even less likely to be true with the update function Damien  
has suggested.

This is an important point for p2p meshes. For my perspective it  
breaks one of my fundamental assumptions: that a p2p mesh will tend  
towards a global steady state. If replication updates become non- 
functional i.e. consistency is dependent on an (impossible to achieve)  
global ordering of change application, then that is no longer true.

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

There are two ways of constructing a software design: One way is to  
make it so simple that there are obviously no deficiencies, and the  
other way is to make it so complicated that there are no obvious  
deficiencies.
   -- C. A. R. Hoare



Mime
View raw message