couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 14:10:04 GMT

On Feb 7, 2009, at 7:45 PM, Damien Katz wrote:

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


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

But this remains possible in the change you are proposing?

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

Which is what it does now too, right?

I won't belabor this - I'm following the other thread - but I just  
have trouble understanding why the mode I'm thinking of has any bigger  
downside than what is being proposed, and why the benefit - the  
ability to do consistent writes on a single node (be it alone or a  
part of a cloud/cluster) is a bad thing.

I understand that there's no magic bullet here - that the non- 
transactional replication means that slaves can be momentarily  
inconsistent (or persistently in the case of catastrophic failure of  
the master) but assuming the master lives or can be brought back, the  
data will be eventually consistent.  However, it seems valuable to  
have the option for system designers of multi-node system (and single- 
node users as well)  to be able to do consistent writes.

Also, to be clear, I'm not arguing against adding new modes - just  
advocating the protection of what I see an existing and useful mode.


View raw message