Session and its events are sometimes peculiarat best and down right complex at worst. This is necessary because ofthe need to service different state providers. I examine some of theseissues which may help explain why session end and session start eventsdon?t always seem to fire as a couple.
The glue which holds the matrix together is anoften overlooked bad boy called session id. Here is how he plays apivotal role in this new world. Session start event fires for each newrequest. Session end event fires based on the state of the session id.This behavior causes confusion with the expectation of session endevents.
Consider a frustrated programmer who puts codein the session end event and patiently waits for it to fire in order todo some clean up and write to the database. Her code is based on thefaulty assumption that a new page request must have fired a session endevent. Building on this faulty premise, her well-intentioned codemisbehaves.
In order to fix it, let's try to understandhow it works. A couple of key turns are important to note with thesession id. If session id is regenerated, this ultimately triggers asession end event. If the session id is not regenerated, that is, theexisting id is used to service a new request, then the session endevent will not fire. Expanding the picture a bit, let?s take a look atwhat causes new session id's to be generated. A new session id isgenerated if two conditions are fulfilled.
- The session dictionary associated with the session must be written to at least once
- At least one request must have been completed successfully.
If neither of these conditions is satisfied, session start and session end will not behave as a harmonious couple.
With this in mind, it is entirely trivial toconstruct a test case where several new page requests are createdwithout triggering the session end event. It is also easy to causesession start and session end events to fire as a couple. The key pointto remember is that the mutually inclusive condition previouslymentioned must be fully satisfied.
Lets examine another creature,session.abandon(). Depending on which side of the table you sit, shebehaves weirdly because she may sometimes call session end or she maynot. Here is how this ingredient fits into the .NET soup.Session.Abandon may call session end if the mode is set to inproc. It'seasy to draw the wrong conclusions because if you build a page, placesession.abandon as the first line session end will not fire. This slideof hand causes one to conclude, rather erroneously, that session endisn't fired when sessionabandon is invoked. Again, the condition has not been fully satisified.
The Abandon method will destroy the session bysending a new session id cookie with an old expiration date. Then,abandon destroys the dictionary associated with the session. Whethersession end event fires next is entirely dependent on the session id.It bears repeating: If the session id is regenerated, session end eventfires. If the session id is not regenerated, session end fails to fire.So in one case, calling session abandon will invoke the session endevent. And in another case, calling session abandon does not cause thesession end event to fire. Admittedly, It?s strange behavior when youdon?t see the whole picture.
One more thing to note. If the session id isbeing re-used then this session id is kept until the browser is closedeven though a new page is requested. As long as the conditions aresatisfied, the session id remains. Armed with this knowledge, saidprogrammer can now adjust her code to make it work correctly.
Here is the complete test case exampleprotected System.Web.UI.WebControls.Button Button1;
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
//removing the next line of code causes the
//condition to only be partially satisified
Session["test"] = "test";
//session end will not be called if the next line is uncommented
//because the conditions are only partially satisified
//Session.Abandon();
}
private void Button1_Click(object sender, System.EventArgs e)
{
//session end will be called here because both
//mutually inclusive events satisfy the condtion
Session.Abandon();
}