Better Understanding of State Management in ASP.Net

For some time I've been using all of these special ASP.Net objects to assist with state management:

• Cache
• Application
• Session

Up until now though, I was misinformed about something. I had thought that when I retrieved a complex object out of one of these state management objects that I was getting a copy of it. In this way, I could do some work on the "temporary object" but then had to save it back in order for the change to be permanent.

This is absolutely incorrect!

So, for example:

DataTable dtEmployees = (DataTable)Session["Employees"];
DataRow row = dtEmployees.Rows[5];
row["FirstName"] = "Steve";

I do NOT have to use the following line:

Session["Employees"] = dtEmployees;

Rather, right after the name was changed above, I could have done this:

((DataTable)Session["Employees"]).Rows[5]["FirstName"]

and "Steve" would be returned!

How to Redirect to Login Page after a Session Timeout

In ASP.Net 2.0 applications there's a special event handler called "Session_End" that exists in Global.asax. It is fired when the Session Timeout occurs.

I use this event handler to write key Session variables (all DataTables at the moment) out to a special holding area within the associated database. The next time the user logs in, these same Session variables are restored with the previous data. In this way the user is protected from losing valuable work if they step away from their computer for a moment.

I did some testing and was a little surprised to discover that when such a timeout occurs, the browser just stays on the page it was before. This is clearly a problem, both for security reasons (an unattended corporate app should log itself off) and because the Session variables were now all null. Eventually I heard from a bright developer from New England named Mike Banavige who succinctly explained the situation this way:

Session end does not occur in the context of an http request. It is simply a timeout that occurs on the server. Since there is no request involved in the timeout, there is nothing to redirect.

Put another way, the Session_End event is occurring strictly on the server - the client doesn't know a thing about it. Makes perfect sense - why didn't I think of that!

So what to do with the predicament of the web app remaining on the same page, even though the Session has timed out? Well, more research revealed the answer. Within the Page_Load event handler of my master page codefile, I added this:

Response.AddHeader("Refresh", Convert.ToString((Session.Timeout * 60) + 5));
if (Session.IsNewSession)
Tools.PageRedirect("~/Login/login");

Since every web page in my app utilizes the master page, this Refresh meta tag is inserted into each of them. And because it's in the Page_Load event handler, it gets updated (moved forward) every time a postback occurs. With a typical 5 or 10 minute session timeout, it's highly unlikely that the user would be working on something that long without a postback occurring. It thus serves as an effective way to implement a Logout due to User Inactivity feature.