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'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.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There is nothing more difficult to plan, more doubtful of success, nor
more dangerous to manage than the creation of a new order of things...
Whenever his enemies have the ability to attack the innovator, they do
so with the passion of partisans, while the others defend him
sluggishly, So that the innovator and his party alike are vulnerable.
-- Niccolo Machiavelli, 1513, The Prince.