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
replicate.
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?"
