On Thu, Oct 21, 2010 at 21:03, Thomas Müller <thomas.muel...@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).
Agreed. >> 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. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
