couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 00:45:53 GMT

On Feb 7, 2009, at 6:49 PM, Geir Magnusson Jr. wrote:

> On Feb 7, 2009, at 6:05 PM, Damien Katz wrote:
>> On Feb 7, 2009, at 5:08 PM, Geir Magnusson Jr. wrote:
>>> On Feb 7, 2009, at 11:22 AM, Damien Katz wrote:
>>>> On Feb 7, 2009, at 11:02 AM, Geir Magnusson Jr. wrote:
>>>>> Thanks for the info.  Is there a third mode possible?  Namely  
>>>>> all or nothing  with conflict check,  with the understanimg that  
>>>>> the conflict guarantee is only at commit, and all bets are off  
>>>>> after that when replicated?
>>>> That's what we currently have. It's possible to keep supporting  
>>>> it, but it doesn't work with any of CouchDB's distributed  
>>>> features. It's only appropriate for a single node instance, even  
>>>> a hot standby slave will have inconsistent states.
>>> Sure...  Assuming we're defining things the same way, I think that  
>>> the existing mode still might be useful - I could consider a node  
>>> to be the "reference master" for my data (or a subset) and vector  
>>> all writes there with whatever consistency promises I get from a  
>>> single node, and then everyone else will be eventually consistent,  
>>> and I'd know that the eventually consistent nodes have a  
>>> transactionally consistent data set?
>>> I realize I may not attach the same meaning to concepts, but can  
>>> you get a sense of what I'm saying?
>> So a single master node that always in a valid state, inter- 
>> document wise, but slaves nodes are in an unknown inter-document  
>> state (could be a valid state, could be a inconsistent,  
>> transitional state). Unfortunately it can't be used for failover  
>> purposes as the slaves nodes might be in inconsistent inter- 
>> document states. And if the readers need to read dbs in a  
>> consistent state, then it doesn't work for read-only slaves either.
> I understand - my POV is that they'd eventually get into a  
> consistent state assuming the master doesn't go down.
> If the master goes down, they could, but that's what I think I'd get  
> with what you are proposing nayway.

When the master goes down and the slaves aren't in a consistent state  
at the time, then they will never be until the master comes up. Also  
the slaves won't know if they are in an consistent state or not.  If  
the master fails hard (disk failure), then slaves will never regain  
>> I think this works in situations where you have only a single  
>> machine (no replication, no failover), or your app can have read  
>> only slaves nodes where readers don't care about db consistency  
>> (but still no failover). I'm not sure that fits many real world use  
>> cases.
> But how is the end result different from what you are proposing to  
> change to?and-fro

The difference is the guarantee that is made about inter-document  
consistency. The new model is to only guarantees that multi-documents  
are safely saved to stable storage and won't be lost. There may be  
conflicts, but the documents are still there, completely intact  

An example where this is useful in the case where you want rename, or  
move, a document. This involves deleting one document and creating  
another. It may be acceptable that temporarily there are 2 or 0 copies  
of the document as the replication works out, but we know that  
eventually we'll have the documents in the correct final states.


> geir
>> -Damien

View raw message