Question

I’ve read several threads about this topic and need some clarification on a few sentences I read in a book:

If you store your Session state in-process, your application is not scalable. The reason for this is that the Session object is stored on one particular server. Therefore storing Session state in-process will not work with a web farm.

1. What does “scalable” in the first sentence mean?
2. Does the third sentence means if my app resides on a shared web host, I shouldn’t use Session[“myData”] to store my stuff? If so, what should I use?

Thanks.

Answer 1

ASP.NET can store all the combined Session information for an Application (the “Session State”) in 3 possible places on the server-side (client cookies is also possible but that is a different story):

• “InProc” (In Process) which means in memory on the IIS server attached to the asp.net worker process,
• “StateServer” which is a separate process that can be accessed by multiple IIS servers but still stores the Session state in memory, and
• “SQLServer” which stores the Session state in a SQL Server database.

1) The reason In-process is not scalable is if your needs exceed the capacity of a single IIS server, multiple servers can’t use an In-process session state. If you have determined a shared hosting scenario will fulfill you needs, you don’t need to worry about it.

2) When you store something in Session["Name"], ASP.net stores that data wherever the application is configured to store Session state. If you want to change where Session state is stored, all you need to do is configure your web.config file. If you are using a shared hosting environment, your IIS deployment is considered single server even though no doubt the actual servers are in a farm of some sort.

See: MSDN Session-State Modes