couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: couchdb transactions changes
Date Sat, 07 Feb 2009 23:49:23 GMT

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.

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

geir

>
>
> -Damien


Mime
View raw message