CODEWITHSUNDEEP
c#asp.netazure
user152949
user152949

Reputation:

ASP.NET Application-state provider

I've so far implemented several custom multi-tenant providers for Azure Table Store like a ASP.NET Session-state provider, ASP.NET Virtual Path Provider, a.s.f. I would now like to implement a custom multi-tenant ASP.NET Application-State provider, but I have not found any resources or best practices online.

In the example below I show how I would like to use the ASP.NET Application-State provider to keep track of number of online users across all my Azure Web application nodes:

void Session_Start(object sender, EventArgs e)
{
    Application["NumOnlineUsers"] = ((int)Application["NumOnlineUsers"] + 1);
}

void Session_End(object sender, EventArgs e)
{
    Application["NumOnlineUsers"] = ((int)Application["NumOnlineUsers"] - 1);
}

How can I implement a ASP.NET Application-State Provider where I persist the application-state data in the Azure Table Store?

Upvotes: 1

Views: 405

Answers (1)

welegan
welegan

Reputation: 3043

The link in your question states the following assumptions about ApplicationState:

  • Volatility: Because application state is stored in server memory, it is lost whenever the application is stopped or restarted.

  • Resources: Because it is stored in memory, application state is very fast compared to saving data to disk or a database.

  • Scalability: Application state is not shared among multiple servers serving the same application

A provider like you suggested would change the volatility (because the data would live elsewhere and could be restored), as well as enable scalability (because multiple ApplicationStates could then share the values). However it comes at the cost of the simplicity that that page suggests for ApplicationState.

In short, it sounds like .NET intended for this data structure to hold values necessary for a single instance of an application that did not need to persist across process restarts. If you are using it in that sense, it may be worth considering a different data structure than ApplicationState rather than bending through hoops to make it something it was not envisioned to be. Even if you did manage to write the persistence layer, think about the last point they bring up:

  • Concurrency: Application state is free-threaded, which means that application state data can be accessed simultaneously by many threads.

How do you support that when you introduce the lag and fallibility involved with talking to an Azure table, presumably on another virtual machine or at least on a different process? What happens when thread 1 makes a change to a value, then thread 2 changes it back, but the change from thread 2 gets written to disk first then thread 1? After reboot, you would have no idea what the expected value would be.

In short, I don't think you should write it. It's not a tool that is needed, and breaks intended use (although that alone is not enough to say it shouldn't be written). The final nail in the coffin is that it's not feasible because Microsoft did not expose the same granularity for extending it that they did with the SessionStateProvider class.

Upvotes: 1

Related Questions