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 Sat, 07 Feb 2009 23:05:43 GMT

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


View raw message