ASP.NET Tips: Careful Use of Static's

re: ASP.NET Tips: Careful Use of Static's

Raj — Mon, 02 Mar 2009 17:42:55 GMT

Here is a sample webpage that shows the dangers of using static variables in an ASP.Net website without understanding its consequences:

http://www.aggregatedintelligence.com/Samples/StaticsDemo/default.aspx

And my explanation:

http://blog.aggregatedintelligence.com/2009/01/static-variables-and-their-implications.html

re: ASP.NET Tips: Careful Use of Static's

Dave Black — Fri, 19 Sep 2008 18:59:37 GMT

Just to underscore some things (Tom already answered a few):

1. User-specific values should really be stored in Session. You could use client-side cookies if there is not any security sensitive info in there (e.g. username, password, etc.). Also, client-side cookies are limited to 4K in length. ASP.NET Personalization and WebParts is an option for WebPart kind of things. If the values are meant only to be held for the life of the ASP.NET page, you could also use Viewstate (again don't place security-sensitive info here since ViewState is only Base64 Encoded and not encrypted).

***As a security note, you should *not* store password in Session or in Cookies in case the Session or Cookie is hijacked (which is trivial to do).***

2. Application-wide or "shared" values should really be stored in the Cache. These values can be seen and accessed by anyone in the AppDomain, so be careful not to put sensitive or user-specific values in there. Another option is to use Application variables. However, it is recommended to use the Cache.

3. Initialization of Static variables in Thread-safe in all versions of .NET. This is why the Singleton Pattern uses static variables for its implementation.

4. The use of Static Constructors should be carefully considered. You should use Static Initializers (or inline initialization of a static variable - i.e. inline where it is declared) when possible. The CLR is able to optimize the performance of types that have not explicitly defined a static constructor. One case of this is with the use of NGEN. The biggest difference of use of a static constructor vs. inline static variable initialization is the timing of when each happens. The majority of the time you shouldn't, and don't, care about when your static variables are initialized. However, if it is of importance, the CLR will initialiaize inline static vars. whenever it wants to. On the other hand, the firing ofa static constructor is guaranteed to happen right before the first static member is accessed. Note that *all* static members who are not explicitly initialized inline are initialized once the static constructor fires. Obviously if you needed to do additional things with a static variable after it has been initialized, you would need to use a static constructor instead of inline initialization.

HTH

re: ASP.NET Tips: Careful Use of Static's

ASP.NET Debugging — Fri, 19 Sep 2008 15:25:24 GMT

rtpHarry,

No that shouldn't cause any problems. The application is meant to handle multiple threads all calling a static function at the same time. No problem with that.

re: ASP.NET Tips: Careful Use of Static's

ASP.NET Debugging — Fri, 19 Sep 2008 15:24:30 GMT

bobh,

Yes, if the data is private to each user, session is a good place to store it.

re: ASP.NET Tips: Careful Use of Static's

rtpHarry — Fri, 19 Sep 2008 13:02:39 GMT

If my data layer has static functions such as update and two requests come in at the same time could this potentially cause problems?

re: ASP.NET Tips: Careful Use of Static's

bobh — Fri, 19 Sep 2008 11:46:24 GMT

So what would the solution be to persist data for only the current user? Store it in the session?

re: ASP.NET Tips: Careful Use of Static's

Dave Black — Fri, 19 Sep 2008 06:53:39 GMT

The scope of a static variable is limited to an Application Domain.

re: ASP.NET Tips: Careful Use of Static's

Muhammad Mosa — Thu, 18 Sep 2008 20:50:55 GMT

Yes this is a good point talk about, last month someone raised a post regarding this in ASP.NET Forums

http://forums.asp.net/t/1302762.aspx

thanks for sharing

re: ASP.NET Tips: Careful Use of Static's

ASP.NET Debugging — Thu, 18 Sep 2008 19:44:11 GMT

Nick,

the ' was just cause of spellcheck. And I didn't catch it to change it back. It depends on what you mean by global, but if you mean that other can access that bit of memory, that it is global. If you mean any part of the application can access it, then you are right, it is not.

re: ASP.NET Tips: Careful Use of Static's

Sumit — Thu, 18 Sep 2008 19:36:52 GMT

Absolutely rite Torn.....we faced that kinna prblm in past because of static global variables in a multiple server environment.