On Tue, Oct 19, 2010 at 12:24, Thomas Müller <thomas.muel...@day.com> wrote: > Instead, the cluster nodes should merge each others changes > asynchronously (except operations like JCR locking, plus potentially > other operations that are not that common; maybe even node move). With > "asynchronously" I mean usually within a second or so, but potentially > minutes later depending on configuration, latency between cluster > nodes, and possibly load. Similar to NoSQL systems.
It would be really cool if this configuration could by by path. For example: /banking/accounts => immediately consistent /website/comments => eventually consistent AFAIK all/most NoSQL systems don't allow that, or can't, because they miss a content structure to base the configuration on (everything is a document with some generic ID string). Configuring this for the entire repository or workspace OTOH would break the benefit of JCR to integrate different applications in one system. I think implementation is fairly simple, as it only has to be handled at the sender: a session.save() that includes changes with "immediate consistency" would be synced over the cluster as it is now (using some fsync()-like protocol command), "eventual consistent" changes would go into the asynchronous cluster queue and make the save() call return as fast as a pure local one. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
