This is really disappointing for us. Through this revisioning, Oak has turned a datastore that is consistent by default into a datastore that is not :p 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... and the cluster that involves a single shared source of truth (mongo/rdbms), and should have the easiest time being consistent, is not. Hehe. Ahh this probably shoots down our entire Sling proof of concept project.
Our next step is to measure the consequences of moving forward with Sling+Oak+Mongo and not-sticky sessions. I'm going to try to test this, and get an empirical answer, by deploying to some AWS instances. I'll develop a custom AuthenticationHandler so that authentication is stateless and then we'll try to see how bad the "delay" might be. However, I would love a theoretical answer as well, if you've got one :) chetan mehrotra wrote > sticky > ... sticky sessions would be required due to eventual consistent nature of > repository. Okay, but if we disable stick sessions ANYHOW (because in our environment we must), how much time delay are we talking, do you think, in realistic practice? We might be able to solve this by giving user-feedback that covers up for the sync delay. When a user clicks save, they might just go to a different screen, providing enough time for things to sync up. It might be a race condition, but that might be acceptable if we can choose that architecture on good information. I think that, in theory, the answer to "worst case scenario" for eventual consistency is always "forever," but really... How long could a Sling instance take to get to the latest revision? 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? 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? A performance cost for this might be tolerable -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069661.html Sent from the Sling - Users mailing list archive at Nabble.com.
