When using InProc session state, the session will be stored locally on the server that served the request, and therefore, using the same machine key on both servers will not serve this purpose.
This option is not suitable for use in a web farm environment. One farm computer stores session state, but not another. Subsequent web requests from the same user may not read the correct session state.
Consider a very common scenario:
Imagine that the web request is redirected to machine A, and the code called by the request depends on some parameters stored in the session. If the same user is then directed to machine B in the next web request, which also depends on the state of the session, then the results will be unpredictable.
There is something called StickySessions that can solve the above scenario. But is it really good?
This function means that if the client returns for the second request, then the load balancer will redirect this traffic to the same web server. It is also called customer proximity. This can be important for web servers that locally store session state, so when the same visitor returns, we don’t want the state relevant to this user to be unavailable because the request was redirected to another web server.
This definitely matches the goal of load balancing in the web farm. We must avoid this decision so that the load balancer can choose the “right” machine in the farm based on the current load.
Read here for a complete understanding: http://dotnetcodr.com/2013/07/01/web-farms-in-net-and-iis-part-5-session-state-management/
RC
source share