incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Newbie questions
Date Wed, 24 Sep 2008 09:48:21 GMT

On Sep 24, 2008, at 10:15 , Ayende Rahien wrote:

> On Wed, Sep 24, 2008 at 11:04 AM, Jan Lehnardt <jan@apache.org> wrote:
>
>>
>> How do you ensure that across a cluster, all nodes will select the  
>> same
>>> version?
>>> Assume that I have the following sequence of events:
>>> - create doc A (v1)
>>> - update doc A from V1 (v2)
>>> - update doc A from v1 (v3) - conflict
>>> - update doc A from v1 on separate machine (v?) - conflict
>>> How does it get resolved?
>>>
>>
>> There are two types of conflicts here. update conflicts and  
>> replication
>> conflicts.
>>
>> You cannot update doc A from V1 to V3.
>>
>
> Can I try to update a document that was already updated?
> Let us say that I get v1, and update it, and try to save, while at  
> the same
> time someone else saved.
> What is going to happen? optimistic concurrency error? save and  
> produce
> conflict?

optimistic concurrency error. you need to specify the revision you  
want to
update. if it doesn't match, CouchDB won't let you update.

>
>
>
>>
>> - server 1: create doc A(V1)
>> - replicate server 1 and server 2
>> (doc A now lives on server 1 and server 2 with V1)
>> - server 1: update doc A(V1) to doc A(V2a)
>> - server 2: update doc A(V1) to doc a(V2b)
>> (now there are two V2 for doc A). No problem so far)
>> - replicate server 1 and server 2:
>> - CouchDB sees that V2a and V2b are different and decides
>>  either one to be the latest revision. Say V2a gets chosen.
>> - Server 1 and server 2 now both have doc A (V2a) as the
>>  latest revision, but doc a is flagged with a _conflict attribute.
>> - You need to go in and resolve that by wither approving CouchDB's
>>  automatic choice or by using a previous revision. There is no  
>> merging
>>  and there is no auto-conflict-resolution. Only auto-conflict- 
>> detection.
>>
>
> Okay, I see how this works for 2 servers. What happen if we have  
> three?
> So now we have V2a, v2b, v2c.
> Server 1 replicate with server 2 (v2a is chosen)
> Server 3 replicate with server 3 (v2? is chosen)

you mean
Server 1 replicate with server 3
or
Server 2 replicate with server 3 :-)

> What is going on with server 2? On next replication, it will get  
> whatever
> was chosen by 1 & 3 ?

In any case ,after replicating server 1 & 2 they look the same.
So when you replicate either with a new server, you fall back
to the case of V2a vs. V2b (where V2b is actually V2c).

If there are new conflicts introduced by conflict resolutions,
you start over with V2a and V2b being the first resolution and
the newly conflicting change.



>
>
>
>
>>
>>> to get from the code so far are:
>>>>
>>>>> - How is the data stored? I think that it is a binary tree on  
>>>>> disk, but
>>>>> I
>>>>> am
>>>>> not following how updates to that can be safe to do so with ACID
>>>>> guarantees.
>>>>>
>>>>> Two questions that are of particular interest to me, and I  
>>>>> haven't been
>>>> able
>>>>
>>>> Writes are serialized. Only one write can happen at a time and it  
>>>> is
>>>> completely
>>>> flushed and committed to disk (2 x fsync()) before another write  
>>>> comes
>>>> in.
>>>> Writes
>>>> are append-only. No data is ever overwritten. This gives us the  
>>>> ACID &
>>>> MVCC
>>>> buzzcronyms :-)
>>>>
>>>>
>>> Can you speak more on the actual file format? I don't think that I
>>> understand how you can have append only with binary trees.
>>>
>>
>>
>> I have to refer you to Damien or the source for that one. :-)
>>
>
> Trolling the sources now, but it is pretty hard to figure it out.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message