why my HttpContext.Application variable cannot be access through different Actions in ASP.NET MVC

i created a aspnet mvc program, and i want some variables can be shared to every visitor.
i typed some code into Global.asax:

protected void Application_Start(){ 
    SMEQueue[] SMEtime = new SMEQueue[10];
    Application["waittime"] = SMEtime;

however, i can’t modify the array in Application. i can read it in every Actions in Contyoller like this:

SMEQueue[] arr = System.Web.HttpContext.Current.Application["waittime"] as SMEQueue[];

but after i change the values in the array in a Action, what i get in other Actions is still the original array assigned in Global.asax. the modification cannot pass to other Actions.
why and what can i do?
i found there are many similar questions on stackoverflow, sadly their answers do not work well for mine.

more codes:
i edit the variable in a Action:

public ActionResult Create()
        SMEQueue[] arr = System.Web.HttpContext.Current.Application["waittime"] as SMEQueue[];
        arr[0] = new SMEQueue("hello");//elements of arr are null before

then i access it from another Action:

public ActionResult TryConnect()
        SMEQueue[] arr = System.Web.HttpContext.Current.Application["waittime"] as SMEQueue[];
        Request.Write(arr[0].ToString());//it' null.

if i assign some value to a variable in Application_Start(), i can access the value anywhere (any Actions). but after i modify the value in any Action, what i read in other Actions is still the value assigned in Application_Start().

Here is Solutions:

We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.

Solution 1

You first need to understand that Application objects are often created more than once. Therefore different requests may well be using different Application objects. So it makes sense that one Action could be reading your start up values rather than your modified values because they are being handled by different Application objects.

Disadvantages of Application State:

Application scope The scope of application state can also be a
disadvantage. Variables stored in application state are global only to
the particular process the application is running in, and each
application process can have different values. Therefore, you cannot
rely on application state to store unique values or update global
counters in Web-garden and Web-farm server configurations.

ASP.NET State Management Recommendations

A classic example you will likely encounter is IIS winding down your application due to inactivity which is by default 20 minutes i believe. When the next request hits the server a new worker process will be spun up with a new Application object and therefore state.

So basically if you need to maintain state beyond a single session and Application, you need some form of state persistence, typically a database, that you write/read through too.

I would be using:

  • HttpContext for short lived per user per request storage
  • Cookies for long lived per user multi request storage
  • Cache for long lived multi user, multi request data
  • Application State for global lookup data that doesn’t much (daily, weekly, monthly) bearing in mind you’ll have to manage the wind down, spin up from old to new data.
  • And finally be reaching out to the db or some other efficient read/write medium for the type of thing you seem to be trying to do / page counters etc.

To test all of this simply put a breakpoint on your Application_Start code and see how many times it gets hit, every time it does that’s a new Application object in play…. plus looking at your threads in the Debug Windows of VS can be informative.

Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply