In the In-Proc Session mode, the session has "affinity" with the server. I.e. Session Id only exists in the memory of that one server to which the first request hits.

That means that if www.mydomain.com is the first server the user ever hits, the user will get an ASPSESSIONID that only exists in the memory of that one server.

To guarantee the user gets back to his/her session on the next HTTP Request (when you have more than one server), - Requires using "Sticky Connections" or Node-Affinity feature of your Load-Balancer.

I.E. if you want your application to run in a server-cluster/server-farm, then you need to make sure that you use "Sticky Sessions" feature of your load-balancer.

When you load balance your ASP.Net application(or any web application), the sticky session ensures that all the subsequent request will be send to the server who handled the first request corresponding to that request.

The problem with sticky sessions is that they limit your application scalability because the load balancer is unable to truly balance the load each time it receives request from a client.

With sticky sessions, the load balancer is forced to send all the requests to their original server where the session state was created even though that server might be heavily loaded and there might be another less-loaded server available to take on this request.

Better Solution:

The answer to all of this is to have Session State Truly Clustered. This way, it does not matter on which server the session was actually created because the session lives in the entire cluster.

The user request can then be forwarded by the load-balancer to the most appropriate server. This approach is also highly scalable and there is no single point of failure.

Sticky sessions work with the load balancer to improve efficiency of Persistent Sessions in a clustered configuration. In a clustered configuration, the load balancer sends requests to multiple backend Resin servers. Each session has an owning Resin server and a backup Resin server. The load balancer will send a session's request to the owning server or to the backup if the owning server is not available.

The association of a session with a backend server is called "Sticky Sessions".

Because the load balancing occurs before any interpretation of the Virtual Host or Web Application, it's a <server> configuration variable, with the <session-cookie> tag.