jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <jus...@justinedelson.com>
Subject Re: [jr3] Clustering: Scalable Writes / Asynchronous Change Merging
Date Tue, 19 Oct 2010 21:17:11 GMT
On Tue, Oct 19, 2010 at 4:14 PM, Alexander Klimetschek <aklimets@day.com> wrote:
> 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.
This would be quite cool.

> 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.
You'd also need to ensure that a single session.save() which touched
both "immediately" and "eventually" consistent nodes forces a queue
flush (or at least a queue flush of changesets which touched the same
set of eventually consistent nodes). This is possibly the trickiest
part of the implementation.

Justin

>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>

Mime
View raw message