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] Write skew
Date Thu, 01 Dec 2011 13:26:06 GMT

On 1.12.11 13:01, Jukka Zitting 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?

Currently the microkernel does nothing about this. That's what this 
whole discussion is about after all ;-)

Eventually consistent approaches are IMO very hard to get right with JCR 
since most operation are assumed to be persisted after dispatch. One 
solution I see is to have changes caused by conflict resolution (i.e. 
during convergence) to appear as normal changes as if they where done by 
other sessions (see [1]). This would however require changing the 
revision model of the microkernel from linear shaped to tree shaped.

For the current problem I'd rather have the microkernel to expose some 
test-and-set semantics as Tom describes in [2]. That way a client of the 
microkernel could apply changes atomically.

A third and most general solution which puts away with write skew for 
good is described in [3]. This requires examining the commit log for 
certain read-write conflicts on save.



[2] http://markmail.org/message/c32jpeoxklgcrybr

[3] http://dl.acm.org/citation.cfm?id=1376690

View raw message