On Tue, Jan 17, 2017 at 1:46 AM, lancedolan <lance.do...@gmail.com> wrote: > It's ironic that the cluster which involves multiple datastores (tar), and > thus should have a harder time being consistent, is the one that can > accomplish consistency..
Thats not how it is. Cluster which involves multiple datastores (tar) is also eventually consistent. Changes are either "pushed" to each tar instance via some replication or changes done on one of the cluster node surfaces on other via reverse replication. In either case change done is not immediately visible on other cluster nodes > More importantly, is it a function of Repo size, or repo activity? > If the repo grows in size (number of nodes) and grows in use (number of > writes/sec) does this impact how frequently Sling Cluster instances grab the > most recent revision? Its somewhat related to number of writes and is not dependent on repo size > Less importantly... Myself and colleagues are really curious as to why > jackrabbit is implemented this way. Is there a performance benefit to being > eventually, when the shared datastore is actually consistent? What's the > reasoning for not always hitting the latest data? Also... Is there any way > to force all reads to read the most recent revision, perhaps through some > configuration? Thats a question best suited for discussion on oak-dev mailing list (oak-...@jackrabbit.apache.org) Chetan Mehrotra
