Chetan, I'd like to confirm to what degree that is true for our proposed architecture. It seems that only the OSGI configurations and bundles would be "eventually consistent." It seems the only "state" that is stored in Sling instances are OSGI configurations and OSGI bundles. Everything else is in the JCR, which Mongo can provide as strongly consistent ( I believe ). Consider this example and correct me where I'm wrong. I'd hate to shoot myself in the foot with bad assumptions.
Imagine 3 Sling instances all talking to 1 Mongo instance. In this case, it seems to me that all REPO state is captured in a single Mongo instance, which is consistent by default and eventually consistency only happens if you hit secondary members of a Mongo Replica Set. In an architecture with only one Mongo instance, the moment one instance writes to the JCR, another instance will read the same data and agree consistently. It seems to me that the JCR state is strongly consistent. However, OSGI configurations seem to propagate to each other through the JCR only eventually... Additionally, when we deploy a new OSGI bundle to the JCR (in an install directory or whatever), then those seem to only eventually propagate to all Sling instances. I'm not totally sure that these are "eventually," but it seems like the only place that state will only be "eventual" in this architecture. So, as long as we're cool with OSGI configurations and bundle installations being eventual, everything else, stored in the JCR, should be strongly consistent right? And then, I believe we can even scale the Mongo instances into a replica set for better availability and we'll still be strongly consistent so long as all Sling instances only read from the primary member of the replica set: [1]. Thanks for your time and thoughts dude! [1] https://www.mongodb.com/faq#consistency -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069551.html Sent from the Sling - Users mailing list archive at Nabble.com.
