Ok First of all - I GENUINELY appreciate the heck out of your time, and patience!!
... and THIS is really interesting: If THIS is true: chetan mehrotra wrote > If you are running a cluster with Sling on Oak/Mongo then sticky > sessions would be required due to eventual consistent nature of > repository. and THIS is true: chetan mehrotra wrote > Cluster which involves multiple datastores (tar) > is also eventually consistent. Then why is adobe recommending it's multi-million-dollar projects to go stateless with the encapsulated token here, if those architectures are *also* eventually: https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html If "being eventual" is the reason we can't go stateless, then how is adobe getting away with it if we know their architecture is also eventual?? What am I missing? I understand that the documentation I linked is a distributed segment store architecture and mine is a share documentstore datastore, but what is the REASON for them allowing a stateless (not sticky) architecture, if the REASON is not eventual consistency ? Both architectures are eventual. Again, thanks for your patience and sticking with me on this one... whoa pun! -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069698.html Sent from the Sling - Users mailing list archive at Nabble.com.
