re:
Application is faster because it's all in memory
Both cache data and compiled, cached,
aspx pages are also "in memory".
Regarding performance concerns, see :
http://msdn.microsoft.com/library/d.../en-us/cpguide/html/cpconApplicationState.asp
Application-state variables are, in effect, global variables for a given
ASP.NET application. Like client-side application developers,
ASP.NET programmers should always consider the impact of
storing anything as a global variable.
The following issues are particularly important in this context:
1. The memory impact of storing something in application state.
The memory occupied by variables stored in application state
is not released until the value is either removed or replaced
That is not a concern when using web.config.
2. The concurrency and synchronization implications of storing
and accessing a global variable within a multithreaded server environment.
That is not a concern when using web.config.
3. The scalability implications of storing and accessing
a global variable within a multithreaded server environment.
That is not a concern when using web.config.
Regarding Locks ( like the ones you recommended ) :
Application.Lock()
Application.Unlock()
Locks should be used whenever an attempt is made to write
or update a file. Locks that protect global resources are
themselves global, and code running on multiple threads
accessing global resources ultimately ends up contending
on these locks.
This causes the operating system to block the worker threads
until the lock becomes available. In high-load server environments,
this blocking can cause severe thread thrashing on the system.
On multiprocessor systems, it can lead to processor underutilization
(since all the threads for a processor theoretically can be stalled while
waiting for a shared lock) and significant drops in overall scalability.
That is not a concern when using web.config.
4. The life-cycle implications of information stored in application state.
That is not a concern when using web.config.
5. Application state is not shared across a Web farm
(in which an application is hosted by multiple servers)
or a Web garden (in which an application is hosted by
multiple processes on the same server).
Variables stored in application state in either of those scenarios
are global only to the particular process in which the application
is running.
Each application process can have different values.
Therefore, you cannot rely on application state to store
unique values or update global counters, for example,
in Web farm and Web garden scenarios.
That is not a concern when using web.config.
re:
(except maybe it's not fast when the server is under heavy load.)
That alone would make me shy away from the use of Global.asax's
Application_OnStart as a data repository to be accessed during
an application's lifetime.
In short, although speed is not the only consideration, I haven't
seen *anybody* recommending the use of variables stored
at the Global Application level, except for very small tidbits
which are updated once in a blue moon.
Probably the fastest way to retrieve a small amount of stored
data would be to declare it as a variable in an assembly,
and to retrieve and cache the result.
For not-too-intensive traffic websites, short strings stored in
web.config is one of the easiest storage/retrieval methods to
implement, is reliable, and is fast enough.
Juan T. Llibre
===========