jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Behaviour of Move Operations
Date Fri, 01 Mar 2013 13:27:17 GMT


On 1.3.13 12:52, Felix Meschberger wrote:
> Hi,
>
> Am 01.03.2013 um 13:47 schrieb Michael Dürig:
>
>>
>>
>> What Jukka is saying is that the repository gives you a choice between
>> consistency and availability. Since both you cannot have.
>
> I think you don't want to given the user that choice ...
>
> I'd opt for best possible availability (or probably you mean performance?) with "guaranteed"
consistency.

One point of Oak is exactly that: to provide a sensible way for trading 
off consistency for availability. While I agree that consistency is 
important it should however not have an impact on scenarios where it is 
irrelevant. Other NoSQL systems have similar means for such a trade offs.

See 
http://blog.mongodb.org/post/523516007/on-distributed-consistency-part-6-consistency-chart

and http://en.wikipedia.org/wiki/CAP_theorem for some background.

Michael

>
> Regards
> Felix
>
>>
>> Michael
>>
>> On 1.3.13 12:40, Felix Meschberger wrote:
>>> So you essentially say: Behaviour of the repository is "best effort" and we --
at the  end of the day -- cannot trust the repository ?
>>>
>>> Sounds frightening.
>>>
>>> IMHO the repository should be failsafe and thus eventually solve the issue making
sure we don't end up with two copies of the same node (actually both copies, if referenceable,
will even have the same node ID....
>>>
>>> Regards
>>> Felix
>>>
>>> Am 27.02.2013 um 16:35 schrieb Jukka Zitting:
>>>
>>>> Hi,
>>>>
>>>> On Wed, Feb 27, 2013 at 5:09 PM, Carsten Ziegeler <cziegeler@apache.org>
wrote:
>>>>> How will this be handled with Oak? Could it happen that due to this
>>>>> happening concurrently that the node ends up twice in the repository
>>>>> (at /1/node and /2/node in my example)?
>>>>
>>>> The behavior depends on the underlying MicroKernel implementation.
>>>>
>>>> With the new SegmentMK I've been working on, you can control the behavior:
>>>>
>>>> * If both cluster nodes use the same (root) journal, then only one of
>>>> them succeeds and the other one will fail with an exception. The
>>>> behavior is more or less the same as with current Jackrabbit.
>>>>
>>>> * If the cluster nodes use different journals (with background
>>>> merging), then one of the moves will succeed and depending on timing
>>>> the other one either fails or ends up producing a duplicate copy of
>>>> the tree.
>>>>
>>>> The latter option is designed to boost write concurrency in scenarios
>>>> where it's OK for some operations to get lost or produce somewhat
>>>> inconsistent results (high-volume commenting or logging systems,
>>>> etc.). Operations for which such behavior is not desirable should use
>>>> the first option.
>>>>
>>>> BR,
>>>>
>>>> Jukka Zitting
>>>
>>>
>>> --
>>> Felix Meschberger | Principal Scientist | Adobe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>

Mime
View raw message