What are the common issues and best practices when using ASP.NET session state?

Question

For example, I make extensive use of the session in my ASP.NET application but have heard somewhere that objects stored in session can be removed by the system where server memory runs low. Is this true? Is there any session 'callback' functionality to allow you to re-populate scavenged objects?

More generally, what other potential problems of using session state are there, and what are the suggested best practices for dealing with them?

Answer 1

Sorry, I don't know about the removal of items from session state, but in response to your general question, the most important question is whether you anticipate running your web app on just one web server machine or many.

Typically, you are keeping the session state in the memory of one single machine. Your load balancer that fronts your multiple web servers must be configured to make things "sticky", so that the same user keeps being routed to the same machine.

Alternatively, you could store session state in a central location, including SQL Server, but then you pay the performance hit for the network and IO interaction with SQL Server. You give up the speed of local, in memory state.

Since session state is 20 minutes by default, if you need more than that, but your hosting company won't let you override it, you would have to have some ajax or hidden iframe javascript code running in your web pages that would ping the server every (less than) 20 minutes to keep the session aliv

Answer 2

And every time the Application pool is restarted as well, for example, create a page that sets a session variable and show it in the page, now, update you BIN, APPCode, Global or Local Resources folder and you will see that the session will be erased.

And in Shared Hosting environments that will be trickier cause they block the session timeout to normally 20 minutes, no matter what Session.Timeout value you override.

For this and more reasons I do use SQL Sessions, the web application is a little bit slowly cause everything (sessions) are in a SQL Server instead in memory, but you have much more control on it and you can set the session timeout to whatever you want! Very good in my case because I want them to continue working while I'm updating the application (was very bad that every time I updated the APP Code folder all the user would loose what they were working and had to login again) and I want to extend the shared hosting 20 minutes to 45.

Read more about SQL Session State

Answer 3

No matter which precautions you use, always assume your Session may disappear and double check:

Dim sessionObj As Object = CType(Session("SessionKey"), Object)
If sessionObj Is Nothing
    sessionObj = ReCreateObj()
    Session("SessionKey") = sessionObj
End If

object sessionObj = Session["SessionKey"] as object ;
if(sessionObj == null)
{
    sessionObj = ReCreateObj();
    Session["SessionKey"] = sessionObj;
}

A Session wrapper works well for this so you don't have the check everywhere you access your Session vars.

I've had good luck with custom Session-State Providers. A couple useful tweaks include:

• When using a database-backed Session, fetch all of your Session vars at the beginning of the request and store them all at the end versus fetch per access/store per set. This is useful if you're using more than a couple Session vars as it cuts down on round trips to an external server.
• Implement a two-step memory/database store. On save, store your var in memory on the local server and save to the database as well. When accessed, check memory first (if you find it here, you save a network hop), then the database.

I'd definitely see if one of three standard Session modes works before implementing something you'll have to support. Custom Sessions are useful once you know more about your app's quirky needs.