Is there a bug with this design?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.