jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: [jr3] Clustering: Scalable Writes / Asynchronous Change Merging
Date Fri, 22 Oct 2010 04:54:15 GMT

> 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".

It seems I was unclear. This is exactly what I *don't* want for
Jackrabbit 3. In the current Jackrabbit implementation, the
storage.save() call indeed returns only when the change is available
on all cluster nodes. And that is exactly what doesn't scale. What I
want for Jackrabbit 3 is: the storage.save() call on a cluster node
returns as soon as the data was written on *this* cluster node
(locally). But not on *other* cluster nodes. As I already wrote,
"cluster nodes should merge each others changes asynchronously".

> the observation listeners will be called out of order

Not necessarily. The spec doesn't say when observation listeners are
called (I don't talk about synchronous observation listeners here,
because they are not part of the spec). Regular observation listeners
might be called 1 second or 1 minute after the event. Now if
Jackrabbit 3 would guarantee to asynchronously merge changes within 2
seconds, and delay delivering local events, then Jackrabbit 3 could
deliver the events in the right order.

> with clustering you tend to ignore external events in observation listeners anyway

Yes, many application ignore such events. However Jackrabbit must
still deliver them.


View raw message