On Feb 9, 2009, at 7:22 AM, Antony Blakey wrote:
On 09/02/2009, at 10:09 PM, Antony Blakey wrote:
On 09/02/2009, at 9:33 PM, Antony Blakey wrote:
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.
Actually, that could form the first part of the new compound revs
Assuming the replication processes doesn't interleave documents from
different MVCC commits,
I believe that's correct.
I'm now thinking that all that is needed is for each rev to include
a MVCC commit # (== transaction id); commit #'s would be allocated
at the start of an MVCC transaction (because they would be needed
within the commit), and hence would not be a strict ordering. You
can then detect MVCC commit boundaries by detecting when the commit
# changes. No change required to the source replicator, and target
replication could take advantage of that at some future stage.
This would allow for consistent replication of transactions, if they
were provided, with replication possible at a MVCC commit
granularity i.e. no problem with huge replications.
But we still have the problem that ...
On Feb 9, 2009, at 12:58 AM, Antony Blakey wrote:
The document revision created in the _bulk_docs will still show up
in the replication stream - it does now doesn't it?
No, not necessarily. Each doc shows up exactly once in the
replication stream -- at the update_sequence of its latest revision.
Best,
Adam
