Maintaining ASP.NET Session State in an Ajax Application

Recently, I’ve been working with applications that require very few postbacks. While this has been great from a usability perspective, after all the application is very ajaxy and responsive, it’s caused some unexpected problems. One problem that it caused is that ASP.NET Sessions were expiring even though the user was actively using the application.

The Sessions were expiring because the user wasn’t causing a postback (full or partial) and thus executing the ASP.NET page life cycle, which takes care of maintaining Session for us by implementing the IRequireSessionState interface.

One way I could have solved this problem is to rehydrate Session whenever an Ajax request was received (such as by marking the web method as requiring Session), but this is a bad programming practice for a few reasons. First, having Session attached to a request and response isn’t very RESTful and breaks at least a couple of design rules. Second, it’s a relatively expensive operation to pull Session from the session store, deserialize it into the Session object, use it, maybe modify it, and then serialize it back out to the Session store when the request is complete. As Session gets bigger, this operation gets more expensive and I really want the Ajax features of the application to fly. Finally, I might not own the REST endpoints that I’m using for my application’s functionality. In that case, I’m talking to a third party service (i.e. Amazon’s S3 service), and not communicating at all with my application, but I still need to keep Session alive. The user doesn’t know or care that I’m talking to Amazon. They just think they’re using my application.

What I really wanted to do was sometimes revalidate Session while the user interacted with the Ajaxy parts of the application without the user paying any perceivable performance penalty and not breaking too many rules of application design.

To do this, I created a mechanism to execute a fire and forget request to a custom Http Handler that takes care of revalidating Session for us.

[Download the code here]

First, let’s cover the the custom Http Handler:

using System.Web;
using System.Web.SessionState;

public class OutOfBandSessionValidator : IHttpHandler, IRequiresSessionState
{
    public bool IsReusable
    {
        get { return false; }
    }

    public void ProcessRequest(HttpContext context)
    { }
}

As you can see, out OutOfBandSessionValidator does almost nothing. The only thing really worth noting is that it implements the IRequiresSessionState interface that tells ASP.NET that when a request comes in, this handler requires that Session be retrieved and deserialized, and when the request completes, it serializes the Session object and stores it back in the Session store. This is the mechanism that will allow us to keep Session alive.

We wire up out custom handler just like any other Http Handler in the web.config like so:

<httpHandlers>
...
    <add verb="GET,HEAD" path="OutOfBandSessionValidator.ashx" type="OutOfBandSessionValidator"/>
...

</httpHandlers>

(This is IIS 6 style.)
We can now access our custom handler like so: http://localhost:1544/OutOfBandSessionValidator.ashx

Now that we’ve got our handler wired up, we need to create a mechanism to call it. For performance purposes, we want to call the handler in a way that doesn’t affect our application’s performance (perceived or real) and we don’t want to call it too often. Rather, we want to call it once a minute or something like that. We’re going to wrap this functionality in a custom component. In the custom component we’re going to reply on a Client EventPool event to talk to our component rather than call into it directly. This way, we don’t really need to have a link to the component.
First, for posterity, let’s redefine our Client EventPool. (For more information on the Client EventPool, see this post.)

_EventPool = function() {
    _EventPool.initializeBase(this);
};
_EventPool.prototype = {
    addEvent: function(name, handler) {
        this.get_events().addHandler(name, handler);
    },
    removeEvent: function(name, handler) {
        this.get_events().removeHandler(name, handler);
    },
    raiseEvent: function(name, source, args) {
        var handler = this.get_events().getHandler(name);
        if (handler) {
            handler(source, args);
        }
    }
};
_EventPool.registerClass("_EventPool", Sys.Component);
var $evp = $create(_EventPool, { "id": "EventPool" }, null, null, null);

Now we can define our OutOfBandSessionValidator component and a custom event args class:

RevalidateSessionArgs = function(ticks) {
    RevalidateSessionArgs.initializeBase(this);
    this._ticks = ticks;
};
RevalidateSessionArgs.prototype = {
    get_ticks: function() { return this._ticks; }
};
RevalidateSessionArgs.registerClass("RevalidateSessionArgs", Sys.EventArgs);

_OutOfBandSessionValidator = function() {
    _OutOfBandSessionValidator.initializeBase(this);
    this._revalidateSessionDelegate = null;
    this._lastTimeSessionWasValidated = null;
    this._delay = 60000; // default to 60 seconds.
};

_OutOfBandSessionValidator.prototype = {
    set_delay: function(value) { this._delay = value; },
    get_delay: function() { return this._delay; },

    initialize: function() {
        _OutOfBandSessionValidator.callBaseMethod(this, 'initialize');
        this._revalidateSessionDelegate = Function.createDelegate(this, this._revalidateSession);
        $evp.addEvent("RevalidateSession", this._revalidateSessionDelegate);
    },

    dispose: function() {
        if (this._revalidateSessionDelegate !== null) {
            $evp.removeEvent("RevalidateSession", this._revalidateSessionDelegate);
            this._revalidateSessionDelegate = null;
        }
        _OutOfBandSessionValidator.callBaseMethod(this, 'dispose');
    },

    _revalidateSession: function(sender, args) {
        Sys.Debug.trace("_revalidatingSession");
        var revalidate = false;
        if (this._lastTimeSessionWasValidated === null) {
            revalidate = true;
        }
        else if ((args.get_ticks() - this._lastTimeSessionWasValidated) > this._delay) {
            revalidate = true;
        }

        if (revalidate) {
            Sys.Debug.trace("Executing call to OutOfBandSessionValidator.ashx");
            this._lastTimeSessionWasValidated = args.get_ticks();
            var wRequest = new Sys.Net.WebRequest();
            wRequest.set_httpVerb("GET");
            wRequest.set_url("OutOfBandSessionValidator.ashx?d=" + args.get_ticks());

            var executor = new Sys.Net.XMLHttpExecutor();
            wRequest.set_executor(executor);
            executor.executeRequest();
        }
    }
};
_OutOfBandSessionValidator.registerClass("_OutOfBandSessionValidator", Sys.Component);
$create(_OutOfBandSessionValidator, { "id": "OutOfBandSessionValidator" }, null, null, null);

The _OutOfBandSessionValidator component is quite simple. In it's initialize method we wire up a delegate to the "RevalidateSession" event

initialize: function() {
    _OutOfBandSessionValidator.callBaseMethod(this, 'initialize');
    this._revalidateSessionDelegate = Function.createDelegate(this, this._revalidateSession);
    $evp.addEvent("RevalidateSession", this._revalidateSessionDelegate);
},

In the dispose method we clear out this event handler

dispose: function() {
    if (this._revalidateSessionDelegate !== null) {
        $evp.removeEvent("RevalidateSession", this._revalidateSessionDelegate);
        this._revalidateSessionDelegate = null;
    }
    _OutOfBandSessionValidator.callBaseMethod(this, 'dispose');
},

The other method, _revalidateSession, which is executed whenever the “RevalidateSession” event is raised, is responsible for calling our OutOfBandSessionValidator handler not more than whatever delay we set.

_revalidateSession: function(sender, args) {
    Sys.Debug.trace("_revalidatingSession");
    var revalidate = false;
    if (this._lastTimeSessionWasValidated === null) {
        revalidate = true;
    }
    else if ((args.get_ticks() - this._lastTimeSessionWasValidated) > this._delay) {
        revalidate = true;
    }

    if (revalidate) {
        Sys.Debug.trace("Executing call to OutOfBandSessionValidator.ashx");
        this._lastTimeSessionWasValidated = args.get_ticks();
        var wRequest = new Sys.Net.WebRequest();
        wRequest.set_httpVerb("GET");
        wRequest.set_url("OutOfBandSessionValidator.ashx?d=" + args.get_ticks()); 

        var executor = new Sys.Net.XMLHttpExecutor();
        wRequest.set_executor(executor);
        executor.executeRequest();
    }
}

In the _revaidateSession method, the args parameter is of type RevalidateSessionArgs. This custom arguments class contains one property, get_ticks(), which simply holds a ticks value. This value’s intended purpose is to hold the current ticks of the date/time when of when the event args were created. It then performs some checking to make sure that we haven’t initiated a request to OutOfBandSessionValidator.ashx with the delay and then sends a non-cacheable GET request to the OutOfBandSessionValidator.ashx handler.

To use the OutOfBandSessionValidator we raise the RevalidateSession event like so:

$evp.raiseEvent("RevalidateSession", this, new RevalidateSessionArgs(new Date().getTime()));

Now that we have a mechanism for calling the OutOfBandSessionValidator.ashx by raising an event, we can write a small test page that raises the event every 5 seconds. To really illustrate that our mechanism works, we’re going to set the ASP.NET Session timeout to 1 minute in the web.config file.

        <sessionState  mode="InProc" cookieless="true" timeout="1" />
    </system.web>

Here’s our test page’s markup. Note that we have three buttons on the page. The first one causes postback and refreshes the label with the current Session’s information. The other two start and stop the raising of the event.

<body>
    <form id="form1" runat="server">
    <asp:ScriptManager ID="SM1" runat="server">
        <Scripts>
            <asp:ScriptReference Path="~/JS.js" />
        </Scripts>
    </asp:ScriptManager>
    <div>
        <asp:Label ID="lblNewSession" runat="server" />
        <asp:Button ID="btnCausePostback" runat="server" Text="Cause Postback" />
    </div>
    <input type="button" id="btnStopInterval" disabled='disabled' value="Stop Interval"
        onclick="window.clearInterval(window._intervalId);
                 $get('btnStartInterval').disabled = false;
                 $get('btnStopInterval').disabled=true; " />
    <input type="button" id="btnStartInterval" value="Start Interval"
        onclick="window._intervalId=window.setInterval(window.fn, 5000);
        $get('btnStartInterval').disabled = true;
        $get('btnStopInterval').disabled = false;" />
    </form>
</body>

Here’s the test page’s code behind.

public partial class _Default : Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Session["lastAcessTime"] = DateTime.Now;
        if (this.Session.IsNewSession)
        {
            this.lblNewSession.Text = "New Session: " + this.Session.SessionID;
        }
        else
        {
            this.lblNewSession.Text = "Existing Session: " + this.Session.SessionID;
        }
    }
}

Here’s how the page looks when we initially load it.

After waiting 30 seconds or so, and clicking the “Cause Postback” button, we see that we’re working with an existing Session.

After waiting more than one minute and clicking the “Cause Postback” button, we see that the Session is again new.

Now we turn on the interval that is going to raise our RevalidateSession event by clicking the “Start” button.

Note: for this test, I reduced the delay between requests from 60 seconds to 20 seconds.
Looking at the debug window of Visual Studio, we can see that our event is being raised every 5 seconds, but besides the first request, not until the 4th request (20 second mark) do we see the debug message that we’ve initiated a request to the OutOfBandSessionValidator.ashx.

Again, after another 4 requests we see the request to the OutOfBandSessionValidator.ashx

Now when I click the “Cause Postback” I get the existing Session message

When I click the “Stop” button, wait about a minute or so and then click the “Cause Postback” button, you’ll see that the Session has started over.

So there you have it. My take on how to keep an ASP.NET Session alive in an Ajax application.

My final thought is this. It doesn’t make much sense to raise the event every 10 seconds or something like in order to keep the Session alive. Session timeouts are there for a reason. If you never wanted the Session to timeout a better way would be to increase the Session timeout to some ridiculous number. Rather, it is much better to raise the event in response to a user’s action. The user panned the map, requested a property detail, clicked a drop down list, etc. If you get real clever, you’ll figure out that you should centralize this event raising and figure out a way to write the code once and have it executed automatically.