couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Replication and forms of weak consistency
Date Mon, 16 Feb 2009 23:51:36 GMT
On Mon, Feb 16, 2009 at 11:10 PM, Antony Blakey <antony.blakey@gmail.com> wrote:
>
> On 17/02/2009, at 9:26 AM, Robert Newson wrote:
>
>>> The point of doing it in the server is that every node guarantees
>>> Monotonic
>>> Writes, and you never have to worry about failing because you can't
>>> achieve
>>> it. Given the current server implementation, IMO it's more likely than
>>> not
>>> that you would fail.
>>
>> This comment leaves me puzzled which is entirely the fault of my poor,
>> tired brain.
>
> More likely my poor explanation. Current CouchDB replication semantics are
> very unfriendly to Monotonic Writes, because they only replicate the data of
> the head revision (and conflict sources). Compaction makes it theoretically
> worse by deleting data that wouldn't get replicated, but I say theoretically
> because compaction is only a barrier to fixing the problem - replication
> already acts as though constant compaction was occurring. The proposed
> revision stemming does however make it practically worse because all records
> of writes disappear from a prefix of the document revisions, and such
> removal occurs at multiple unaligned points in the linear write log. There's
> no equivalent to Bayou's handling of log truncation.
>
> I haven't described an alternative to the current multi-node proposal (which
> isn't a formal proposal). My comments purely concern the current
> implementation of single-node operation and replication.

Ok, now I do understand. This matches my surprise at the replication
strategy. Two partitioned nodes make local changes, they both
cross-replicate, but each node does not have the full revision history
of the other, they don't converge to the same state. The only promise
is that the revision of each document will be the same at both nodes
after successful, bi-directional replication. It's that behavior that
breaks MW. I'm so used to replication using write-ahead logs (where
all replicas see all intermediate states) that I have to consciously
recall that CouchDB doesn't do that.

I can also see how revision stemming would make it worse. Perhaps my
hope of layering session guarantees over CouchDB is doomed without
core changes. Good to know before I expended the effort. :)

The More You Know ...

>
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> He who would make his own liberty secure, must guard even his enemy from
> repression.
>  -- Thomas Paine
>
>
>

Mime
View raw message