couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
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  
controversy.
   -- Martin Luther King



Mime
View raw message