Scope of Static Variable in Multi-User ASP.NET Web Application

Scope of static Variable in multi-user ASP.NET web application

Does static variables retain their values across user sessions?

Yes, that's why you should be VERY careful when you use static variables in a web app. You will run in concurrency issues as more than one thread servicing a request can modify the value of the variable.

While this works in single-user environment, What happens if there are
2 users simultaneously logged in from two computers, User 1 sets the
value as 100, then User 2 sets the value as 200. after that user 1
invokes the Get Value button. What will he see as the value?

The user will see 200 afterwards.

static variables in asp.net/C#

Personally I try to avoid static variables as much as possible. They make the code difficult to unit test and also could introduce subtle bugs due to concurrent access and race conditions.

As far as your requirement is concerned you could use store the variable as a property of the control in the ViewState. If it is user specific data that you are trying to store then you could use the Session state.

Replacing static variables in .net web application

Here is your class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

public class Accounting
{
    public static Accounting Current
    {
        get
        {
            return (HttpContext.Current.Items["Accounting"] ??
                (HttpContext.Current.Items["Accounting"] = 
                new Accounting())) as Accounting;

        }
    }

    public String currentFile = "";
    public List<string> PurchaseOrder = new List<string>();
    public List<string> item = new List<string>();
    public List<string> unitPrice = new List<string>();
    public List<string> shippingCharge = new List<string>();
    public List<string> handlingCharge = new List<string>();
    public List<string> discountAmount = new List<string>();
    public List<string> UOM = new List<string>();
    public List<string> invoiceNumber = new List<string>();
    public List<string> supplierNumber = new List<string>(); //{ get; set; }
    public List<string> supplierInvoiceNo = new List<string>();
    public List<string> account = new List<string>();
    public List<string> fund = new List<string>();
    public List<string> org = new List<string>();
    public List<string> prog = new List<string>();
    public List<string> activity = new List<string>();
    public List<string> location = new List<string>();
    public List<string> distributionType = new List<string>();
    public List<string> distributionValue = new List<string>();
    public List<int> sequence = new List<int>();
    public List<string> quantity = new List<string>();
    public List<string> dueDate = new List<string>();
}

You can use the singleton like that: Accounting::Current.quantity

Note:

Using a static class is an antipattern in OOP. A static class is like a namespaced collection of method. You cannot instantiate objects that preventing you from using inheritance, interfaces, low coupling, dependency injection, ... Always use a singleton instead. This will help you to make a better architecture. You also should take a look at SOA (Service Oriented Architecture) in OOP and then in HTTP (REST webservices).

Static variables in asp.net?

Yes, there can be conflicts. You can end up with a lot of unexpected behaviors. Avoid them as you may have concurrency issues.

value of ASP.NET variables for different users

A simple rule - you need to choose storage as per the scope of data being stored. And for any mutable (read/write) shared state, you have worry about concurrent access (thread safety). For example, if a variable is a static then it would available through-out application (correctly speaking app-domain) but it also means you have ensure thread-safety while reading/writing the variable. Here are few tips

1. For per request scope, use local variables. No need for thread-safety (as only request thread would access it).
2. For per page scope (over repeated post-backs), use view-state. No need for thread-safety (as only request thread would access it).
3. For per user scope, use session state. A good thing about session state is that you don't have to worry about thread-safety (ASP.NET take care of that).
4. For application wide scope (strictly speaking app-domain wide scope), use application state or static variables. Application State offers lock/unlock API for thread-safety while for static variables, you have put your own locking mechanism. Static variables are good bet for application wide read-only data i.e. you initialize them at the start of application and then use the information whenever needed w/o locking because there are no writes.
5. For any scope larger than this, use database (or any other persistent data store). For database, transactions are used to ensure consistency.

What is better: Static variable V.S. Asp.NET Application Session?

If you only have one of those, there is little difference.

If you have several, you should use static variables rather than Application variables. The Application.Lock method will lock all Application variables, while you can use separate syncronisition identifiers for your static variables, so that each lock only affects the code that accesses that specific variable.

static variable and application object

Any of the Application object\static object approach would fail in a multi server scenario. If your state sharing is more of a read only view of some data things may work, but in a read-write scenario things would fail. In such a scenario you need delegate state storage to another machine altogether (such as state server, sql server, memcache etc).

If you compare static and application object i would strongly suggest you to go with Application object as it has some thread synchronization built into it, which can help avoid inconsistent data retrieval.

---

Related Topics