couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 16:23:29 GMT
On Mon, Feb 9, 2009 at 11:16 AM, Adam Kocoloski
<adam.kocoloski@gmail.com> wrote:
> 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 think it's only correct if you don't edit the doc after the
_bulk_docs call. Making two calls to _bulk_docs and then editing a
document from the first transaction would make things interleave I
think.

>> 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
>

Mime
View raw message