Session - Where Is It Stored?

In an effort to increase my postings I've decided to just do some little "tidbits" here and there about random developer stuff. The technical level will be quite basic usually but may require some basic knowledge of .Net.

So for the first one I want to just talk about 'Session' in ASP.NET. You may have used it to store objects for a particular user so that the information is available between page requests. For example, before the Membership Provider, you might have had code in a login page that looks like this:

User user = User.FindByUserName(txtUserName.Text);
if (user.Password == txtPassword.Text) {
   // Valid login, put user in session
   Session["CurrentUser"] = user;
}

So where exactly is this being stored? Well session can be managed different ways. Out of the box, a new web project will store session in a process that comes with IIS. This means it sits in memory permanently, and if IIS gets reset, or the application pool gets reset, then the session is lost. I'm sure we've all experienced this when we rebuild our web app.

There are, however, other options. Via a configuration in your web.config, you can tell your application to store session objects in other locations. You can store them in a dedicated service running on the same, or a different, machine. Once again, this is 'in memory' which means if the service is restarted, the session is lost. However the advantage is that the service can be running on another machine, and if IIS or the app pool needs a reboot, the session is not lost. A third option is to store session information in a database like Sql Server. This is great because no matter what, session information is never lost (pending a corrupt database of course). However storing session objects in a database can have some overhead.

There is no "best" option. It really depends on what your app needs. But consider this scenario: your application is HUGE and is scaled across a web farm (several servers serving your website). Each server runs IIS. This means there are multiple in-proc session locations. Session objects in one server won't be available in another. This means if user X requests a page and logs in after being served from server A, they might then click on a page that gets served from server B where the session object doesn't exist; they get prompted to login again! This is where a dedicated state-server or database storage becomes extremely useful.

That's all I wanted to say. You can read more about it in this article from codeproject.com.

Technorati Tags: ASP.NET, Session, Sql Server