jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3 microkernel] Change log consolidation
Date Tue, 07 Feb 2012 11:32:51 GMT
> The more interesting problem is the conflict handling against a committed
> changelist, or a concurrently applied changelist (thinking of a
> distributed cluster). Maybe the same approach using operations to merge
> concurrent changes (instead of operations vs. persisted state) can be used
> here. If you don't have to look at the state (i.e. possibly the entire
> repository), things might be faster or less memory intensive.
>
> This sounds similar to the Operational transformation (OT) approach [0]
> used for concurrent text editors. However, OT turns out to be quite
> difficult to formally prove even for insert/remove actions in a text, when
> concurrency comes into play. With hierarchy operations, this might even be
> more complex. But maybe worth a thought at least (and more Mathematicians
> like Michi :-) on the team).

Thanks for that link. I've seen this quite some time ago but forgot 
about it... In fact, my approach partially resembles this AFAIU it: 
change the order of operations and if necessary transform them to 
accommodate for the reversed order of execution. Since so far this is 
consolidation only (in contrast to merging concurrent changes) it is 
much simpler though. The gap in complexity can easily be seen in my 
rules 1. - 16.: many of them don't ever apply (the ones marked as 
illegal). That is, they can't ever occur in non concurrent change logs. 
When merging concurrent change logs however the situation is different. 
Then many if not all of these cases would need to be handled as well.

Michael


>
> [0] http://en.wikipedia.org/wiki/Operational_transformation
>
> Cheers,
> Alex
>
> On 06.02.12 12:30, "Thomas Mueller"<mueller@adobe.com>  wrote:
>
>
>> Hi,
>>
>>> An alternative that AFAICT achieves the same effect in perhaps an
>>> easier to understand manner would be to use the state of the content
>>> tree instead of changes to that state as the key concept. Instead of a
>>> commit(changeLog, baseState) method we could have a commit(newState,
>>> baseState) method for persisting changes.
>>
>> That's what I implemented for my first prototype (sandbox/jackrabbit-j3).
>>
>>> PS. You might already have discussed and dismissed this idea off-list.
>>> If yes, what was the deal-breaker?
>>
>> I think the deal breaker is the API, which currently uses the 'diff' style
>> instead of the 'absolute target state' style.
>>
>> For me, it doesn't matter. Either way is fine (diff style or sending the
>> full state). The diff style requires a bit less data to be transferred I
>> guess.
>>
>> However, I personally wouldn't consolidate the change log currently. I
>> don't think it's necessary, and for the normal case (which is _not_ a
>> randomly generated change log, but a manually generated one) I don't think
>> it will help a lot. Also, I don't currently see that would help a lot
>> resolving conflicts. The conflicts it can resolve seem to be weird cases
>> (my opinion, from what I know so far), which are not that important to be
>> resolved. Why would somebody move a node twice? If he does, it's his
>> problem (the applications problem). And why would we want to avoid a
>> conflict if somebody deletes the intermediate node in the meantime? What I
>> mean is, failure to merge such a case would be just fine. Maybe there are
>> other, more important cases that I currently don't know about.
>>
>> I would probably not consolidate the change log, because it simpler not
>> to. Unless it turns out to be a problem in practice (not just in theory).
>> Still, it is an interesting idea.
>>
>> Regards,
>> Thomas
>>
>>
>
>
>

Mime
View raw message