Hi, On Thu, Dec 1, 2011 at 2:26 PM, Michael Dürig <[email protected]> wrote: > Currently the microkernel does nothing about this. That's what this whole > discussion is about after all ;-)
I see this as probably the most significant design decision to be taken for Jackrabbit 3 since the approach taken will have a major impact on repository scalability and performance in terms of concurrent writes. Good that this discussion is happening on the list! > 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. This to me sounds like the best approach to take if only there's a way to solve the problems you mention. The main benefit of an eventually consistent model is that a save() call can safely return without the repository having to synchronizes with other cluster nodes or ultimately even other threads within a single node. > For the current problem I'd rather have the microkernel to expose some > test-and-set semantics as Tom describes in [2]. A test-and-set operation necessarily requires at least some level of atomicity which can quickly become a bottleneck for a clustered setup. > 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. If I understand the paper correctly, also this approach requires synchronization to establish the serialization order of transactions. BR, Jukka Zitting
