A former coworker sent me a note asking me if I had any ideas why his ASP.Net sessions weren’t timing out. One thing came to mind: They may be timing out, but his code may be structured in a way that he won’t recognize it. I’ve seen this in the past when people try to take actions in the Session_End event handler using Session object values. The problem is, you can’t access the Session object from the Session_End event, because the Session object for that user no longer exists at the time the event is fired.
There’s a great article on EggGeadCafe: ASP.Net Session State FAQ. Some of the best items in this article are quoted below:
- “In order for Session_End to be fired, your session state has to exist first. That means you have to store some data in the session state and has completed at least one request.”
- “Session_End is fired internally by the server, based on an internal timer. Thus, there is no HttpRequest associted when that happens. That is why Response.Redirect or Server.Transferdoes not make sense and will not work.”
- “Session state is available only after the HttpApplication.AcquireRequestState event is called.”
- “Q: Will my session state be saved when my page hit an error?
A: No. Unless you call Server.ClearError in your exception handler.”
Good luck to my friend in solving his problem; if the above tips don’t help him out, I’m sure a subsequent blog entry will have more details.