SQL Session State, Response.Redirect() and HttpApplication.Dispose()

Our customer-facing ASP.NET web applications are load balanced, so of course we utilize SQL SessionState.

Thing is, SQL SessionState is much less forgiving than InProc session state. Everything you store must be marked with the Serializable attribute.

Problem is, the application has a funny way of telling you that you've forgotten that important attribute somewhere. Funny in that it doesn't throw an exception when it can't write the item to the session database.

See, the items you store in session during a Request are stored InProc until the ReleaseRequestState event is fired. At that time, the items you've stored in session are written to state. In the case of SQL Session State, this is when the stored procedure to write the data to the database is actually invoked.

In my case, I was storing a business entity in session, to be pulled right back out in the next request. Problem was, it was vanishing between the time it was written and the time the next Request came through, right after a Response.Redirect(). I was getting no exceptions, no indications at all as to what was happening.

After slamming my head against my desk for a couple of days, I found something that will now become a best practice. I call the Dispose() method on the ApplicationInstance of the current request. This manually calls the Dipose() method on each of the httpModules you have registered in your application - and somewhere in there the ReleaseRequestState event is raised. In doing this, I finally got the exception I was looking for - the entity that I was trying to store in session had a property of a type that was not marked Serializable. So I fixed it, and everything is working nicely.

Manually calling Dispose() right after a Response.Redirect() is a nice, clean way of freeing up resources and finishing the current Request in a tidy way. And it helps expose these little issues.