Alternatives to using session variables in ASP.NET (including MVC)

Question

I apologize if this has been asked before, but I haven't quite found the specific question I have in my head.

For the website I am building (using ASP.NET MVC) - performance is an important feature. Also, there is a chance that the site could be hosted in an environment where the Application Pool gets recycled every 20 minutes (or sooner if the memory threshold is reached). I would like to be completely independent of relying on session variables and instead, store a GUID-like value in a cookie. My reasoning is - I don't know how long the session will last because of the AppPool recycling and don't want their session to timeout prematurely and cause them to have to login repeatedly.

The GUID value in the cookie would act as a lookup key to a table where I store session-like information (a user ID value, etc.). So if I needed that data I could retrieve it from the database. I would still make use of the Session_OnEnd event to clear out that session table of rows with a "last activity" value of more than 20 minutes old (or however long sessions are configured to last). So I guess I would still be using session state, just not session variables.

My concern though, again, is about performance. Therefore, I was curious if there are any better methods for avoiding use of session variables while still maintaining the ability to know things about who the user is and manage their visits to the site in a "session-like" way. I am still a newbie to MVC but have plenty of experience in ASP.NET over the years so, I hope my question makes sense!

EDIT: I'm kind of shying away from wanting to use SQL Session State because I will likely be in a shared sql server hosting environment and don't think I will have a login with the ability to create/run jobs if necessary for deletion of expired sql session data, etc. Are there any real drawbacks to depending on Session_OnEnd with a cookie in the AppPool recycling scenario? Could Session_OnEnd not execute for sessions that are current when the AppPool recycles?

Answer 1

You are assuming Sessions are only stored in the working process, you can have SQL State sessions, check this link before going any further

Answer 2

Using a database to provide "durable" persistence across web farms/gardens is a common technique. There are also distributed caching systems that can be used to make session state data available across servers and reboots.

For example, one of the distributed systems I've seen uses UDP to share session data across multiple servers. I would expect there is some performance benefit with distributed cache because the data is stored in memory on the servers, so there is no database lookup.

Answer 3

If you cannot use in-process state, you'll have to revert to an external repository, which will likely be the database.

So why not having the session state stored in the DB? There's built-in support for that, and it solves the recycling issue effectively, while keeping an acceptable performance if the session state is kept small.

Answer 4

Look into a custom caching mechanism. Like you said you cannot use session variables as it sounds like your web site will be load balanced? Sessions may change due to the recycling off the app pool. You also don't want the over head of View State (you could use this but it will impact performance).

There are three key differences between Caching and the other mentioned models:

1. Caching is thread safe
2. Items in cache are removed automatically
3. Items in cache support dependencies