couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 16:16:48 GMT
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.   


View raw message