couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 23:48:28 GMT

On 10/02/2009, at 9:44 AM, Damien Katz wrote:

>
> On Feb 9, 2009, at 5:59 PM, Antony Blakey wrote:
>
>> OK, I give up.
>>
>> Given compaction and/or revision pruning (as Damien has proposed in  
>> another thread), even generic 'Eventual Consistency' isn't  
>> guaranteed.
>
> Revision stemming is 100% optional, and the compaction works the  
> same as it did 0.8.0. I'm not sure why you think 'Eventual  
> Consistency' isn't guaranteed.

Because it depends on a steady state that may never be reached as long  
as modification stays ahead of replication - the 'eventual' point  
might be always ahead of the shared state.

Compaction and revision stemming (which is required to avoid unbounded  
growth) make intermediate states inconsistent because they can delete  
either the data of a document rev or the document rev itself. In the  
face of compaction, it's possible for consistency to only be achieved  
when the replication reaches the same MVCC commit point that the  
compaction was operating against. Revision stemming has a similar  
effect, although it has the further issue of being automatic i.e. not  
scheduled.

That's ignoring replication failure, either temporary or permanent,  
which further complicates the picture. Given that intermediate states  
are not necessarily consistent, anything that leaves you in an  
intermediate state without a way forward, repudiates the guarantee of  
Eventual Consistency.

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

Nothing is really work unless you would rather be doing something else.
   -- J. M. Barre



Mime
View raw message