couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 04:59:23 GMT

On 08/02/2009, at 3:07 PM, Damien Katz wrote:

>> I can't see why this needs to be the case. The fact that there are  
>> peers that have an incomplete replication doesn't stop the master  
>> taking updates - iff the updates to the master are multi-document  
>> ACID.
> Because during downstream replication it may get just some of the  
> documents from a commit that happens during replication. Replication  
> isn't all or nothing, and it doesn't know about transactions

OK, I would have thought that a) replication was relative to a  
specific MVCC commit; and b) a given user-level transaction was all  
within a specific MVCC commit. So the replicator sees at least an MVCC  
consistent view of the updates. Actually, I can't see how replication  
that doesn't respect MVCC commits can work at all, because the  
resultant data would be inconsistent with even the weaker ACID that  
you've proposed.

> The thing is, to avoid all conflicts and inconsistent states, you  
> must read lock the source db during active replication and write  
> lock the target database pretty much until the replication is  
> complete. Otherwise, you'll will get inconsistent states.

Locking for writes is obvious, but read locking the source isn't.

> Does each user get their own local instance of the database?

Not necessarily, and even if they did, it's likely that they'll have  
multiple browser windows open.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The ultimate measure of a man is not where he stands in moments of  
comfort and convenience, but where he stands at times of challenge and  
   -- Martin Luther King

View raw message