Hi, > Network delay .. is faster than the delay of a disk
I wrote ""the network is the new disk" (in terms of bottleneck, in terms of performance problem)". Network delay may be a bit faster now than disk access. But it's *still* a huge bottleneck (compared to in-memory operations), specially if cluster nodes are far apart. If you have the complete repository in-memory, but for each operation you need network access, then the network is the bottleneck. And I don't want that to be the bottleneck. I know I repeat myself, but it looks like this was not clear. > 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." > 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. Regards, Thomas
