jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: [jr3] Clustering: Scalable Writes / Asynchronous Change Merging
Date Tue, 19 Oct 2010 20:14:21 GMT
On Tue, Oct 19, 2010 at 12:24, Thomas Müller <thomas.mueller@day.com> wrote:
> Instead, the cluster nodes should merge each others changes
> asynchronously (except operations like JCR locking, plus potentially
> other operations that are not that common; maybe even node move). With
> "asynchronously" I mean usually within a second or so, but potentially
> minutes later depending on configuration, latency between cluster
> nodes, and possibly load. Similar to NoSQL systems.

It would be really cool if this configuration could by by path. For example:

/banking/accounts => immediately consistent
/website/comments => eventually consistent

AFAIK all/most NoSQL systems don't allow that, or can't, because they
miss a content structure to base the configuration on (everything is a
document with some generic ID string). Configuring this for the entire
repository or workspace OTOH would break the benefit of JCR to
integrate different applications in one system.

I think implementation is fairly simple, as it only has to be handled
at the sender: a session.save() that includes changes with "immediate
consistency" would be synced over the cluster as it is now (using some
fsync()-like protocol command), "eventual consistent" changes would go
into the asynchronous cluster queue and make the save() call return as
fast as a pure local one.


Alexander Klimetschek

View raw message