couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 11:03:37 GMT

On 09/02/2009, at 1:07 PM, Damien Katz wrote:

> would be a big problem of replicating huge databases. Everything  
> must come over in one transaction.

I doesn't *have* to come in one transaction, but I understand the  
problem you are talking about - the commit point may delimit the  
entire database, and always will for the first replication.  
Particularly an issue for me because I'm approaching 4G of data to  

And the problem then with what I've previously suggested is that you  
have to decide before hand whether to fail on a given replication or  
not, and if you don't then you have to maintain a write lock  
potentially for ever, subject to upstream failure. There seems to be  
two solutions to this:

1. Allow a replication rollback commit point (e.g. header) to persist  
so that rollback can occur at any time. This will allow a target to  
abandon a long, incremental replication after several attempts. A  
replication stream would not necessarily end with a commit marker.

2. Record commit boundaries, possibly by recording a transaction-seq  
with each document rev. I'm aware that this *is* about reifying  
underlying transactions, but at least the reification is implicit.

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

A priest, a minister and a rabbi walk into a bar. The bartender says  
"What is this, a joke?"

View raw message