2

I'm completing a feature that was started by a previous developer. I notice that he's loading settings from the db in the Global.asax Application_Start method and puts the settings into HttpContext.Current.Application["SettingName"].

In development this works fine on my machine. If I'm not mistaken though this looks like in production it's going to load the data once when the application starts for the first user but settings will not be available to the application for any subsequent user.

Can someone please confirm or deny my suspicions?

BVernon
  • 3,205
  • 5
  • 28
  • 64

3 Answers3

2

The HttpContext.Current.Application["SettingName"] is a static property. It will be available to the next subsequent users as well. But you can not change it that easy, especial if you use web garden.

You can read more details here: Using static variables instead of Application state in ASP.NET

I do not know how the design is, but you can use a simple static dictionary for the same... of direct read from the database your parameters, or from web.config.

Community
  • 1
  • 1
Aristos
  • 66,005
  • 16
  • 114
  • 150
  • 1
    It is not a static variable. It is a static property that is per http context. The context is per request. – vcsjones Nov 11 '14 at 16:19
  • @vcsjones Make some tests - the context is stay, is not per request - is a static property, that looks on a static dictionary... Only if you have web garden is not stay the same, and depend each time from what pool you look for. – Aristos Nov 11 '14 at 16:23
  • 1
    OK, we are actually both right. `HttpContext.Current` is per-request, but the `Application` is shared across requests. I can't remove my down vote until you make an edit. – vcsjones Nov 11 '14 at 16:26
  • Ok, seems odd to go through the context to get to a static object to put settings in but if it's not a problem then I may leave it for now (as much as it irritates me to do so). – BVernon Nov 11 '14 at 16:34
1

I recommend that you place the settings in the web.config file and use the ConfigurationManager object to read those settings. This is a lot simpler, as there is no need to store them in the HttpContext.

e.g.

<configuration>
    <appSettings>
      <add key="SettingName" value="SettingValue" />
    </appSettings> 
</configuration>

Doing this means the settings will be available to the entire ASP.NET application - there is no need to store them in the HttpContext.

There is a caveat that when you update the web.config file the application pool for the ASP.NET site will be recycled. But the consequences of this all depend on what that site is doing with, for example, session state and caching. Recylcing the application pool will reset those, but that's for another question.....

EDIT:

Based on the comments, it sounds like session state will help you here. With session state, you can store the user specific settings so that they do not interfere with other users.

Jason Evans
  • 28,906
  • 14
  • 90
  • 154
  • Thanks Jason, but these are user modifiable settings. – BVernon Nov 11 '14 at 16:16
  • Also this is one of those applications where I have to try hard not to refactor too much code because I could do that for 6 weeks straight and make zero progress on the actual work I need to do. So I'm just trying to figure out if this is actually going to be a problem before I go and try to solve it :) – BVernon Nov 11 '14 at 16:20
  • I'm thinking a static variable might be more appropriate. Only admin's (not web admins, but admin users of the application) can change the settings (within the app) and when they do it's changed for everyone. – BVernon Nov 11 '14 at 16:29
1

I generally wouldn't touch the HttpContext in Application_Start. In fact, I don't think IIS's Integrated Pipeline will even let you do that.

With integrated pipeline, Application_Start could get fired before any requests even hit the server, such as IIS 8's Application Initialization.

vcsjones
  • 138,677
  • 31
  • 291
  • 286