Can I use static variables in my web application ? what are the alternatives to static ? When I use static variables in pages and more than one user use the application, it makes conflict data (incorrect data).
What are the limits of using static members?
Are static members shared in memory?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Consider storing your shared variables in the HttpApplication object or in the Cache object.
However, if you are trying to store values for each user separately, you should store those values in a Session variable.
Static variables inside Asp.Net are shared in the memory space of the w3svc.exe process and are NOT thread-safe. They can be accessed and modified by any user of the application. This could lead to unwanted modifications, unless you write your own lock mechanism around the storage of those values.
You should try a syntax like:
Application["KEY"] = value;
to store shared application-wide data and
Session["KEY"] = value;
to store data on a per-user basis
You can use the WebCache object to store data in the web server’s memory with expiration conditions. Syntax for that looks similar to:
Page.Cache.Insert("KEY", "VALUE", null, Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration, CacheItemPriority.Normal, null);
More on the syntax of managing the WebCache object can be found at:
http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx
Method 2
Just to add to what @Jeff Fritz has said, an IIS application creates an AppDomain in which your assemblies are loaded. Just like the rules of a normal windows application, if a class such as
public static class Something
{
public static string SomeString { get; set; }
}
…then only a single Something.SomeString property is available per AppDomain. The W3SVC process manages the AppDomain, but the is no guaruntee of thread safety (as an AppDomain can be service multiple requests). If you are using read-only static properties, it’s probably fine (such as reading config values). If you are making mutable properties that change through the lifetime of a request, its better to use one of the storage mechanisms detailed in other questions here.
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