Be careful when using static members in the app_code folder class in ASP. NET Applications

Exercise caution when using static members placed in the app_code class

Each ASP. NET application can add an app_code folder. Classes placed in this folder can be used by all pages in this ASP. NET application. These classes can be called "Global classes" for ease of use.

However, if static members are defined in these classes, you must be careful when accessing these members.

See the following example:

Public class sharedclass

{

Public static int counter = 0;

}

 

Put the above class in app_code. The webpage access code is as follows:

 

Protected void page_load (Object sender, eventargs E)

{

Sharedclass. Counter ++;

Response. Write (sharedclass. Counter. tostring ());

}

 

The above Code seems to have no problem, and the experiment runs normally every time.

However, because web applications are multi-threaded and classes in app_code are global, the above Code will bring about a problem of multi-threaded Data Access conflicts.

We can modify the sharedclass class to highlight this problem:

Private Static int _ counter = 0;

 

Public static int counter

{

Get {

Return sharedclass. _ counter;

}

Set {

Thread. Sleep (new random (). Next (5000,100 00 ));

Sharedclass. _ counter = value;

}

}

The above code simulates the concurrent running environment of programs on the Internet by means of random latency.

The code for accessing shared resources on the page remains unchanged.

Open multiple browser windows to access the same page (or refresh multiple times). Note that the access interval is less than 5 seconds and multiple pages will get the same number. In fact, this number does not actually reflect the number of times shared resources are accessed.

To solve this problem, you can modify the page Code as follows:

Protected void page_load (Object sender, eventargs E)

{

Lock (typeof (sharedclass ))

{

Sharedclass. Counter ++;

Response. Write ("shared resource access times:" + sharedclass. Counter. tostring ());

}

}

 

Use the lock keyword provided by C # to lock the resource. Now, the problem is solved.

Another interesting question is: If shared resources implement access control, do visitors no longer need to write access control code?

To this end, modify the shared resource class again:

Public class sharedclass

{

Private Static int _ counter = 0;

 

Public static int counter

{

Get

{

Lock (typeof (sharedclass ))

{

Return sharedclass. _ counter;

}

}

Set

{

Lock (typeof (sharedclass ))

{

// Random sleep period (5 seconds ~ 10 seconds)

Thread. Sleep (new random (). Next (5000,100 00 ));

Sharedclass. _ counter = value;

}

}

}

 

However, the original page access code remains unchanged:

 

Protected void page_load (Object sender, eventargs E)

{

Sharedclass. Counter ++;

Response. Write (sharedclass. Counter. tostring ());

}

 

What will happen? If you are interested, please give it a try and think about the reasons for this phenomenon.