Currently the microkernel does nothing about this. That's what this whole
discussion is about after all ;-)
and please bear in mind that the microkernel project in the jackrabbit sandbox
is a prototype and represents WIP... ;)
I do. That's exactly why we should challenge it: to discover possible
paint points and to discuss how to handle them.
Michael
cheers
stefan
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
