HI Lance, 2017-01-17 19:19 GMT+01:00 lancedolan <[email protected]>:
> ... > > 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. > > It depends a lot on your usecase. For example Facebook is also eventually consistent (I sometimes think that the timeline is different on every reload). Also the CAP theorem says, that you can choose only 2 of "consistency, atomicity and partition-tolerance". In the case of independent segment stores (in Adobe speak: publish instances, stateless loadbalancing) you have a lot of individual requests from multiple users. So you as an individual cannot decide if another gets the very same content as you. And as long as this eventual consistency is not causing annoyances and friction on and end-user side (e.g. you hit a intra-side link, which returns in a 404), I would not consider it as a problem. And these problems occur so rarely, that many (including me and many other users of AEM) ignore it for daily work. But this is only valid for a readonly usecase! The situation is different on the clustered documentNodeStore (in Adobe speak: authoring, sticky connections). Due to write skew write operations will be visible with a small delay on all cluster nodes. But because there it matters that a user sees the changes he just did. And to overcome this limitation with the write skew, the recommendation is to use sticky-sessions. Jörg -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
