Sheldon Wei
Sheldon Wei

Reputation: 1252

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().

Upvotes: 0

Views: 4665

Answers (1)

rism
rism

Reputation: 12142

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.

Upvotes: 1

Related Questions