couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: couchdb transactions changes
Date Tue, 10 Feb 2009 00:00:20 GMT
On Mon, Feb 9, 2009 at 6:48 PM, Antony Blakey <> wrote:
> 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.

Alas it is true, if you have a system that has operating
characteristics that involved a write load that far outweighs the read
load you actually do break the assumptions that are plastered all over
the documentation.

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

I'm pretty sure the rest of this is wrong though.

> 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

Paul Davis

View raw message