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?