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 Thu, 21 Oct 2010 20:10:56 GMT
On Thu, Oct 21, 2010 at 21:03, Thomas Müller <thomas.mueller@day.com> wrote:
>> importance of leveraging in-memory storage
> In-memory storage *alone* is fast. But if used in combination with the
> current clustering architecture, then writes will not scale. They will
> be just be a bit faster (until you reach the network delay wall).


>> What is then the reason for asynchronous change merging, if not for
>> performance?
> Where did I say it's not about performance? As I already wrote: "it's
> about how to manage cluster nodes that are relatively far apart."

You wrote: "I think the persistence API should be synchronous as it is
now." Which I understand as the persistence layer returning a save()
call only when the entire cluster has been "written to". This is how
it is implemented/expected from persistence managers currently, right?
And this is slow...

>> observation listeners would not always get notified in the same order
> Regular observation listeners are not necessarily the problem, we
> could just delay them until the pre-defined sync delay (until things
> are in sync). The problem are *synchronous* event listeners (as I
> already wrote). The JCR API doesn't actually define them as far as I
> know.

Ah, I didn't see "synchronous".

But still, if you get changes out of order, because a local change is
handled first, while a remote change, that in a total ordering sense
happened before, arrives later at this node, the observation listeners
will be called out of order as well. However, with clustering you tend
to ignore external events in observation listeners anyway, so probably
not a big issue.


Alexander Klimetschek

View raw message