On Thu, Dec 1, 2011 at 2:01 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote:
> Hi,
>
> On Thu, Dec 1, 2011 at 1:13 PM, Michael Dürig <mdue...@apache.org> wrote:
>> But this will introduce a race condition. With other words: this only make
>> the time window during which such a inconsistency could slip in smaller. I
>> think what we'd really need is an atomic test and set operation.
>
> Right, either the refresh-check-persist model for save() needs to be
> atomic (possibly with optimistic locking as described) or we need an
> eventual consistency model that can automatically resolve such
> conflicts.
>
> Has this already been thought about? How does the current microkernel
> implementation handle such cases?
the current microkernel prototype commit roughly works as follows:
1. all changes are persisted
2. within a synchronized block,
2a. - if the head revision has changed since we
started persisting our changes,
a 3-way merge is done starting from the
root node (ideally only the root node
needs to be merged)
2b. - the new head revision is persisted
if an unmergeable conflict is detected in step 2a,
an exception is thrown. that currently only happens
on concurrent property modifications.
details can be found here (doCommit & mergeNode methods) : [0]
cheers
stefan
[0]
http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/model/CommitBuilder.java?view=markup
>
> BR,
>
> Jukka Zitting
