Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Message-Id: <64D18057-3B7F-417E-8D0A-DEE5FD2EC73C@pobox.com>
From: "Geir Magnusson Jr." <geir@pobox.com>
To: dev@couchdb.apache.org
In-Reply-To: <BCBBBDEC-BB49-4B9B-9630-4851DD0F84E3@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: couchdb transactions changes
Date: Sat, 7 Feb 2009 18:49:23 -0500
References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>
 <3B1EB33E-D224-43E2-9FDC-D7493CD5BFDD@pobox.com>
 <59473D22-6EA5-4CE2-A193-8F4938C2D6BB@apache.org>
 <82C6FE57-1BBA-4E71-BDA4-0A1522608FEC@pobox.com>
 <BCBBBDEC-BB49-4B9B-9630-4851DD0F84E3@apache.org>


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