On Tue, Oct 19, 2010 at 4:14 PM, Alexander Klimetschek <aklim...@day.com> wrote: > 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. This would be quite cool.
> 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. You'd also need to ensure that a single session.save() which touched both "immediately" and "eventually" consistent nodes forces a queue flush (or at least a queue flush of changesets which touched the same set of eventually consistent nodes). This is possibly the trickiest part of the implementation. Justin > > Regards, > Alex > > -- > Alexander Klimetschek > alexander.klimetsc...@day.com >
