Hi, > 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. Regards, Thomas
