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 Mon, 06 Feb 2012 12:53:31 GMT


> On Fri, Feb 3, 2012 at 7:44 PM, Michael Dürig<mduerig@apache.org>  wrote:
>> While working on a new transient space implementation [1] I discovered that
>> recreating a list of changes from transient modifications to the hierarchy
>> is like opening a can of worms. Rethinking things it turned out, that it is
>> much simpler to directly consolidate the change log.
>
> Sounds useful, especially for cases where potentially conflicting
> changes need to be merged. The more we can simplify and/or normalize
> changes, the easier merging them is.

Yes that's another reason I was working on this. We have the same 
underlying problem with cluster sync, applying transient changes into 
persistence space and refreshing persistent changes into the transient 
space.

I wasn't thinking about merging based on (consolidated) change logs yet 
but this is a very valid point!

> 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. The backend could then do a
> diff between the two states, which should result in pretty much the
> same list of changes as the proposed change log consolidation
> mechanism. The only tricky part that I can think of is detecting moves
> of non-referenceable nodes, but even that should be doable with hidden
> UUIDs like what we already have in current Jackrabbit.

That's more or less what I started with [1] and what I referred to as 
can of worms in my original mail. Detecting and 
normalizing/consolidating moves turned out to be too tricky there. You 
basically have the same cases I identified (1. - 16.) but its much more 
difficult to tell them apart.

Apart from that, I think there is really a value in having a stateless 
algorithm. And it is really not too hard to understand ;-)

Michael

[1] http://markmail.org/message/qkkcvtmtapas2cx4


>
> The nice thing about such state-based handling of changes is that the
> transient space in any case needs to maintain a representation of the
> state of the modified tree.
>
> PS. You might already have discussed and dismissed this idea off-list.
> If yes, what was the deal-breaker?
>
> BR,
>
> Jukka Zitting

Mime
View raw message