Session variable getting lost?

Question

Given this Global.asax.cs:

using System;
using System.Web;

namespace Foo.Web {
    public class Global : HttpApplication {
        private const string IntroductionPageShownSessionKey = "IntroductionPageShownSessionKey";

        protected void Application_AcquireRequestState(object sender, EventArgs e) {
            ShowIntroductionIfNotYetShown();
        }

        private void ShowIntroductionIfNotYetShown() {
            if (HttpContext.Current.Session != null) {
                var introductionPageShown = Convert.ToBoolean(Session[IntroductionPageShownSessionKey]);
                if (!introductionPageShown) {
                    if (Request.Path.EndsWith("/Introduction.aspx")) {
                        Session[IntroductionPageShownSessionKey] = true;
                    }
                    else {
                        Response.Redirect("~/Introduction.aspx" + Request.Url.Query);
                    }
                }
            }
        }
    }
}

User hits webapp and is shown Introduction.aspx
User continues using webapp for a few minutes (ASP.NET_SessionId: ublbhu45ji31e055ywqu0555)
User falls idle (doesn't perform any postbacks) for a few minutes
User performs postback
User is shown Introduction.aspx
Second inspection of user's ASP.NET_SessionId cookie still shows ublbhu45ji31e055ywqu0555

Why is the user shown Introduction.apsx the second time inside the same ASP.NET Session? I'm familiar w/ the risk in setting session variables just before a redirect in the same postback, but that doesn't apply here, right?

how long is "a few minutes"? long enough to make the session time out? — Sander Rijken, Sep 22 '10 at 15:53
To answer your question: No. My intention w/ including the session IDs was to prove that the session never times out. My understanding is that we're only ever dealing w/ a singular session in this scenario. — lance, Sep 22 '10 at 15:54
The session ID cookie's value is not actually directly tied to the lifetime of the session; that is, the session can time out even though the cookie value is still valid, sent, and accepted. First thing I'd do is check the timeout value for session, and also make sure the AppDomain is not being recycled. — Andrew Barber, Sep 22 '10 at 15:56
I have had this on a few Dev. websites I've worked on. Session in web.config was set to 20 minutes but because of IIS settings the session would time out if you were idle for 5 minutes. Then there is also the case of a new developer fresh out of school who cleans up all variables at the end of their functions... including Sessions. Those are fun. — Ryan Ternier, Sep 22 '10 at 16:01
@Ryan Ternier: The only way I know of, outside of a web.config, to set the ASP.NET timeout is in the ASP.NET web configuration tool (which, then, updates your web.config). My understanding is that the IIS GUI updates not ASP.NET session timeout, but only legacy ASP session timeout? What "IIS settings" would you recommend I check for ASP.NET session timeout? — lance, Sep 22 '10 at 16:05
In fact, an HTTP cookie is a Session cookie when the expiration date hasn't been set (then the expiration is the time the browser is kept open). When the expiration date is set, the cookie is known as persistent — Sander Rijken, Sep 22 '10 at 16:09
@Andrew Barber: You, sir, are the win. My AppDomain is shutting down (proven w/ http://stackoverflow.com/questions/294113/iis-recycle-global-asax/302604#302604). I will credit an answer you create. Thank you. — lance, Sep 22 '10 at 16:15
@Ryan Ternier: I see an IIS GUI there to set idle worker process durations (which only kills sessions if they're in-proc, right?), but no IIS GUI to set ASP.NET session timeouts? Am I missing something? I don't see an IIS GUI for setting ASP.NET session timeouts. — lance, Sep 22 '10 at 17:54

score 0 · Accepted Answer · answered Sep 22 '10 at 18:51

Keep in mind that the Session itself likely has a shorter lifetime than the session cookie being sent to the browser and the ID value set in that cookie. In fact, the browser can continue to submit an old session ID, and the server will accept it and create a new session from it, if the old was expired.

The implications being two possibilities: 1) The session is timing out due to the timeout config value (I know not the case in your particular instance)

2) What we've figured out since in your case via the comments to this question: the AppDomain was shutting down or being recycled.

Session variable getting lost?

1 Answers1