This is not how session works.
When you put a value in the Session the server assign the client an ID and sends it to the client in a cookie. In ASP.NET it's ASP.NET_SessionId
. The client (Browsers) will only send the cookie to the remote address associated with it. If you use Fiddler or browser dev tools you will see the browser sending back the ASP.NET_SessionId
cookie to sessionstatesite1 and not to sessionstatesite2 because it has a different hostname.
You can either add the cookie manually (using browser dev tools for example) and test it again.
If you want to use the cache for user session and have the user access the site using 1 URL that get's routed to different Azure Website Instances, that cache will work fine for you. Again you can verify that using multiple ways. Adding the cookie manually above should show you that it's working. If you wanna do it in an end-to-end flow do this:
- Create an Azure Website
- Scale the site to run on multiple instances
- Configure your site to display the
Process Id
or Instance Id
Environment Variable
- Configure your site to use caching as you already did before
- Store something in session state
- log in to kudu (
https://<yoursitename>.scm.azurewebsites.net
)
- Go to process explorer view (
https://<yoursitename>.scm.azurewebsites.net/ProcessExplorer
) and right click on the w3wp.exe
and kill it (you can also verify the PID there)
- send a request again from the browser, it will go to a different instance and you can tell by the
Process Id
, but the session value will still be saved.