THE CODE:
Session["foo"] = "bar";
Response.Redirect("foo.aspx");
THE PROBLEM:
When foo.aspx reads “foo” from the session, it’s not there. The session is there, but there’s no value for “foo”.
I’ve observed this intermittently in our production environment. But I don’t mean here to ask a question about Response.Redirect().
THE EXPLANATION:
Bertrand Le Roy explains (the bolding is mine):
Now, what Redirect does is to send a
special header to the client so that
it asks the server for a different
page than the one it was waiting for.
Server-side, after sending this
header, Redirect ends the response.
This is a very violent thing to do.
Response.End actually stops the
execution of the page wherever it is
using a ThreadAbortException. What
happens really here is that the
session token gets lost in the battle.
My takeaway there is that Response.Redirect() can be heavy-handed with ending threads. And that can threaten my session writes if they occur too near that heavy-handedness.
THE QUESTION:
What about ASP.NET session management makes it so vulnerable to this? The Response.Redirect() line of code doesn’t begin its execution until the session write line is “finished” — how can it be such a threat to my session write?
What about the session write doesn’t “finish” before the next line of code executes? Are there other scenarios in which session writes are similarly (as though they never occurred) lost?
After testing several alternatives (Response.Redirect(…, false), Server.Transfer(), and other “solutions” I can’t now recall), we’ve found only one reliable answer to this problem.
Moving our session state from InProc to SqlServer effectively eradicated this behavior from our systems, leaving Response.Redirect(…) completely reliable. If further testing shows otherwise, I’ll report here, but I say, to make this stop happening in your environment: move your session state into SqlServer (or is “out of InProc” good enough? I’m not sure).