Alright, this is a deal breaker for our business (if sling absolutely requires sticky sessions). I hope you're not offended that I'm not 100% convinced yet. I understand you do development on the sling project and are well qualified on the topic. To be honest, however, I don't understand fully what you said in your last post and I also know that AEM 6.1 can do what I'd like, which is really just Sling+Oak. If they can do it, I don't understand why we can't.
ref: https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html I'd hate to throw away all the awesome progress we've made with Sling so far when I know that AEM, which is just sling + jackrabbit, can accomplish app-server-agnostic authentication, and thus avoid sticky sessions. Although I don't understand this "head revision" that you've described, and that's inexperience on my part, I am confident that you're telling me that when there is only one Mongo instance in existence, and all Sling instances get data from it, that directly after "sling-instance-1" writes "myProperty=myValue" to the JCR, then "sling-instances-2" could get the value of "myProperty" from somewhere else - some old value. This only seems possible to me if one of the following is true: A) the Sling instances are caching values from Mongo (perhaps Sling or Oak is doing that?) B) There are separate versions of that property stored in Mongo (perhaps this is what you meant by the word revision) and it's possible for a sling-instance to be reading an old version of a property from Mongo. C) Mongo isn't consistent. We know from mongo documentation that C isn't true - Mongo is consistent when reading from the primary replica set. So it must be that A or B is going on? And if so, what is your guess about how AEM 6, which is Sling+Oak, avoids this pitfall when they very clearly support the stateless architecture (ie not-sticky) that I'm planning? -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069605.html Sent from the Sling - Users mailing list archive at Nabble.com.