Extend HttpApplication with session counts and uptime

It’s sometimes useful to know or display how many people are currently using your web application and how long it’s been up for.

As web applications normally inherit from System.Web.HttpApplication we can extend this class with a common re-usable class to add the required functionality.

public class WebApplication : System.Web.HttpApplication {
    private static readonlyDateTime pStartedAt = DateTime.Now;
    private static long pSessionCount = 0;

    public WebApplication() : base() { }

    public override void Init () {
        base.Init();
        HookEventHandlers();
    }

    public static long SessionCount {
        get { return pSessionCount; }
    }

    public static DateTime StartedAt {
        get { return pStartedAt; }
    }
    public static TimeSpan Uptime {
        get { return DateTime.Now.Subtract(pStartedAt); }
    }

    private void HookEventHandlers () {
        IHttpModule httpModule = Modules["Session"];
        if (httpModule is SessionStateModule) {
            SessionStateModule sessionStateModule = ((SessionStateModule) httpModule);
            sessionStateModule.Start += new System.EventHandler(SessionStart);
            sessionStateModule.End += new System.EventHandler(SessionEnd);
        }
    }

    private void SessionStart (object sender, EventArgs e) {
        Interlocked.Increment(ref pSessionCount);
    }

    private void SessionEnd (object sender, EventArgs e) {
        Interlocked.Decrement(ref pSessionCount);
    }
}

The next step is to ensure your web application’s class — as defined by global.asax — is of the new WebApplication type. A good approach is to have your own Global.asax.cs file inherit directly from the new WebApplication;

public class App : WebApplication { ... }

Now those sessions and uptime are being tracked how do you get at them?

lblCurrentSessions.Text = WebApplication.SessionCount.ToString();
lblUptime.Text = WebApplication.Uptime.ToString();

This approach is only suitable for sites operating on a single web server.

[)amien

4 responses to Extend HttpApplication with session counts and uptime

  1. Avatar for

    Information is only used to show your comment. See my Privacy Policy.

  2. Avatar for Steve

    Java’s main problem is the lack of simple out of the box complete frameworks for things like web development — there are lots of really great libs and tools out there (Struts, JSF, XDoclet) but you have to know where to get them and assemble them yourself — it’s strongly decoupled and flexible approach is its own worst enemy, there’s no turnkey version. Trust me, once you get a platform going it’s as productive as .Net but it takes time to build it — impractical on a course (I know, the Java I did in my degree is nothing like what I do for a living). They’ve gone some way to making this better in v5 with Annotations, but it’s still the major reason developers prefer .Net on first sight IMO, .Net hands you more stuff on a plate so it’s quicker to get going.

  3. Avatar for Damien Guard

    Having written a mini eBay for my degree in Java + JSP I can much say I prefer the .NET approach to web development.

  4. Avatar for Steve

    Oh, and I just mentioned this because seeing Interlocked.Increment reminded me. Sorry for the sidetrack.

  5. Avatar for Steve

    Having read up a little on threading in .Net, I have to say I favour the Java approach, but more for what it doesn’t let you do ;). At the higher level there’s not much difference between them really, except for naming issues (instead of wait/notify/notifyAll available on all objects, you have a separate Monitor class with Wait/Pulse/PulseAll — a little odd choice of name but I’ll ignore that). However, .Net clearly lets you get at the more fundamental building blocks of threading, namely at mutexes and semaphores (and the atomic inc/dec/exchange/check&exchange which are simple & ok).

    I can see why that might be useful in some cases, but in my experience threading is such a can of worms it’s nice to have it locked down to the ‘recommended’ approaches for business applications. Mutexes and particularly semaphores (with their lack of thread identity checks) are really, really easy to screw up so if I were using C#, I’d set internal standards to avoid them entirely and stick to Monitor. I guess .Net is being helpful here, but IMO giving these tools to inexperienced coders is like giving a razor to a tartrazine-addled toddler. :)