In ASP.NET, are static class instances specific to a request or a server?

Problem

Are static classes on an ASP.NET website unique to each web request, or are they instantiated as needed and GCed as the GC decides to dispose of them?

The reason I ask is that I’ve developed some static classes in C# before, and the behavior isn’t quite what I expected. I would have assumed that static classes would be unique for each request, but that does not appear to be the case.

Is there a way to make them unique to each request if they aren’t already?

UPDATE: driis’s response was just what I needed. I was already using a singleton class, but it was utilizing a static instance, which meant it was shared between requests even if the users were different, which was a terrible thing in this situation. My problem is totally solved by using HttpContext.Current.Items. Here is my implementation, simplified and streamlined to make the pattern easier to comprehend for anyone who comes across this question in the future:

using System.Collections;
using System.Web;

public class GloballyAccessibleClass
{
    private GloballyAccessibleClass() { }

    public static GloballyAccessibleClass Instance
    {
        get
        {
            IDictionary items = HttpContext.Current.Items;
            if(!items.Contains("TheInstance"))
            {
                items["TheInstance"] = new GloballyAccessibleClass();
            }
            return items["TheInstance"] as GloballyAccessibleClass;
        }
    }
}

Asked by Dan Herbert

Solution #1

All requests to the application share your static classes and static instance data, and they have the same lifetime as the application domain. As a result, you should exercise caution while using static instances, as synchronization difficulties and other issues may arise. Keep in mind that static instances will not be garbage collected before the application pool is renewed, therefore anything referenced by the static instance will not be garbage collected. This can cause issues with memory use.

I recommend using the HttpContext.Current.Items collection if you need an instance with the same lifespan as a request. This is intended to be a spot where you may store items that you’ll need during the request. You can use the Singleton pattern to assist you handle these items for a nicer design and readability. Create a Singleton class that has its instance stored in HttpContext.Current.Items. (For this, I have a generic SingletonRequest class in my ASP.NET common library.)

Answered by driis

Solution #2

Because distinct requests may or may not be handled by the same worker process, static members only have a scope of the current worker process. They have nothing to do with requests.

By the way, the default number of worker processes is 1, which is why so many people on the internet believe that static members have application-wide scope.

Answered by Moshe Bixenshpaner

Solution #3

Because the types are contained within an app domain, I anticipate static classes to be present if the app domain is not recycled or if the request is serviced by a different app domain.

I can think of a few ways to build objects specific to a request, depending on what you want to do with them. For example, you could instantiate the object in Application. BeginRequest, then store it in a HttpRequest object that can be accessed by all objects in the request processing pipeline.

Answered by Sijin

Solution #4

Nope. The ASP.NET process owns static members, which are shared by all Web app users. Other session management strategies, such as session variables, will be required.

Answered by rp.

Solution #5

At the application level, static methods, properties, and classes are prevalent. They are shared as long as the application exists.

The ThreadStatic attribute can be used to indicate a distinct behavior. They’ll be specific to the current thread in that scenario, which I believe is unique to each request. However, I would not recommend this because it appears to be overly difficult.

You can set up HttpContext.Current.Items for a single request, or HttpContext.Current.Session for a single user (across requests).

In general, unless you need to utilize Server.Transfer, the best approach is to create objects once and then transmit them explicitly via method invocation.

Answered by Sklivvz

Post is based on https://stackoverflow.com/questions/194999/are-static-class-instances-unique-to-a-request-or-a-server-in-asp-net