Description
I discovered this in my attempts to write code that handles cache failovers with some grace - as much grace as possible. The only way for me to simulate a cache failure/failover (for testing) is to reboot the cache while a client browser is attempting (in my case through AJAX calls) to access the app, and by extension, the session state.
My test case is a page that initiates two actions repeatedly, each of them one second apart, as AJAX calls. One of those actions is on a controller marked SessionStateBehavior.Readonly, and the other is on a controller marked SessionStateBehavior.Disabled. When the cache fails, I would expect the AJAX call on the "Readonly" controller to be affected, but would not expect the AJAX call on the "Disabled" controller to be affected.
Both AJAX calls typically take about 100ms to complete.
When the cache fails, I would expect the one on the SessionStateBehavior.Readonly controller to take considerably longer while the cache code itself attempts to retry, and then gives up. And in fact this is true - when the cache is in the middle of rebooting, that AJAX call (which ultimately fails) takes about 5 seconds to complete, and completes with a failure.
However, I would expect the one with the SessionStateBehavior.Disabled controller to operate without any delay and to succeed, since it doesn't need to access session state and and is marked that any access to session state would be illegal/violation of contract. And the good news is that it doesn't fail... it does succeed. But it takes it about 5 seconds to succeed, and from this I infer that it is also attempting (unnecessarily) to access the cache.
I would consider this a bug and that the code should be written so that when SessionStateBehavior is disabled, there is no attempt to access the cache.