Cross application instance leaking?

I have an ASP.net web application running in the default application pool. A user has reported getting results returned that were meant for a different user. As far as I know there is no way two users on two different machines should ever see each other's results.

Here is very roughly what the internal structure looks like

namespace SomeApplication
{
 public partial class _Default : System.Web.UI.Page
 {
   static ArrayList results = new ArrayList();

    protected void Button_Click(object sender, EventArgs e)
    {
        // Add data to results 
        // Display in asp:Table element 
     }
  }
}

User1 and User2 were both using the above application at roughly the same moment. User1 got normal results but user2 got a mix of their results and User1's results appear in the asp:Table. 开发者_高级运维

Now I know the results object is in the global scope, but it was my understanding that is this a per-instance of the application object.

Static variables are not user specific, they are global within the ASP.NET worker process currently running. It is entirely possible that this one process served both your users. This means that any code running in the process will see this static variable. Statics are also dangerous because IIS can recycle the worker process at any point it pleases, this will bin the values in the variables.

Instead you may need to use one of the state/caching mechanisms provided in ASP.NET, like Session State:

http://msdn.microsoft.com/en-us/library/ms972429.aspx

As already pointed out by Adam, static variables are not user specific but are per AppDomain. So in ASP.NET scenario where you are running multiple sites in one app-pool, each app-pool process (you can more than one worker process per app pool based on configuration) will have one app domain for each web application. So all your users will share same static variables.

Not only that there is no thread-safty built in for static variables and you can actually see in-consistent data when two different threads are accessing those variables.

For the example that you have sited, you will be better off using a instance variable which corresponds to per request scope (in ASP.NET scenario) but full-fill most of use cases (and you don't have to worry about thread-safty). For data that you want to maintain for the same page over repeated post-back, view-state is the way to go. For data that has more life time, you can choose between Session State, ASP.NET Cache, Application state etc. First two are thread-safe implementations while Application state provides means to lock the slot before accessing them.

Refer these links for various state management options that you have available in ASP.NET:

• http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx
• http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx