jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3 microkernel] Write skew
Date Thu, 01 Dec 2011 13:29:51 GMT
On Thu, Dec 1, 2011 at 2:01 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On Thu, Dec 1, 2011 at 1:13 PM, Michael Dürig <mduerig@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]


[0] http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/model/CommitBuilder.java?view=markup

> BR,
> Jukka Zitting

View raw message