couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 14:34:41 GMT

On Feb 8, 2009, at 9:10 AM, Geir Magnusson Jr. wrote:

>
> 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:
>
> [snip]
>
>>> 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?
>

Nope, because we don't make interdocument consistency guarantees. So  
the database is never in an unacceptably inconsistent state.

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

Because that node must be bullet proof, if it goes down you may lose  
all your inter-document consistency. No hot backup or failover can  
save you. Any number of other databases can do this better than CouchDB

Couch stands for Cluster Of Unreliable Community Hardware. A single  
node that cannot fail without violating application consistency is not  
very Couch-y.

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

And the existing mode can simulated easily from a front end server ,  
so if you are willing to put up will all the downsides and things that  
don't work (or maybe ignorant of its downsides, which is why I don't  
want to make it a real feature), then you can have transactions will  
full conflict checking. You just don't get to use those other features  
and maintain consistency.

-Damien



>
>
> geir
>
>
>


Mime
View raw message