Whilst browsing StackOverflow, I came across an old unanswered question from Feb 10 which caught my eye.
At first, I was quick to dismiss it as nonsense, but then I started looking into it further and became interested. It seems a lot of people are reporting an issue whereby
Session_End is sometimes called immediately after
This can be reproduced in .NET 2.0/3.5 using the following steps:
- Create a new .NET 2.0 WebForms WebApplication
- Configure session for InProc, and set the timeout to 1 minute
- Add a break point on
- Debug the application and F5 to skip the first
Session_Start break point
- Wait until the
Session_End fires after 1 minute
- Refresh the browser, and notice
Session_End is called immediately after
- Note that adding a session variable to the page
OnLoad solves the issue
According to documentation, there are 2 activities that can cause the
Session_End event to fire.
Session.Abandon() is called
- Immediately after the
In this example, neither are
true. So how can this be?
Doing some research on the internet, I found a clue in a blog post on session state. It revealed an interesting quirk about how session state is handled.
This is that ASP.NET will only create a new
InProc session if the session is actually used by the application. If not, then the session is not persisted, and it will not even issue a session cookie (where it doesn't already exist).
So here's what's happening.
When the browser is refreshed after the session timeout, the old session cookie is sent in the request. This causes ASP.NET to reuse the original session ID for a new session. However because at the end of the request the application has not yet used the session, ASP.NET effectively abandons it to avoid persistence and to free resources. This causes an early
Now because ASP.NET does not actually delete the pre-existing session cookie, every subsequent request is essentially restarting the session ID and repeating the sequence of events, such that
Session_End are fired repeatedly until either the session is used or the cookie deleted.
The issue has already been resolved in .NET 4.0. I suspect the session now remains persisted in the case of a session restart.
If your application is using .NET 2.0/3.5 and has expensive code hooked into the session start/end events, then I recommend you add a dummy session variable to your session start routine. This solves the problem by flagging the session as in use, and helps protect your server resources from excessive session events.