On 1.12.11 13:01, Jukka Zitting wrote:
Hi,
On Thu, Dec 1, 2011 at 1:13 PM, Michael Dürig<[email protected]> 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.
Michael
[1]
http://wiki.apache.org/jackrabbit/Clustering%20the%20Microkernel#Replication
[2] http://markmail.org/message/c32jpeoxklgcrybr
[3] http://dl.acm.org/citation.cfm?id=1376690
