Question

I’m having some trouble with understanding how IIS is handling static variables on its threads. My understanding has always been that if IIS has 4 worker processes that it can handle 4 requests simultaneously and that it would be the same as having 4 separate threads running the website. Any static variables would persist in each individual thread. The reason I’m a bit confused is that I have a scope that I’ve made which manages connections and caching transactions. When I’m testing the app I don’t notice any issues but after I’ve compiled it and hit it at the same time from two different locations I seem to get a sort of conflict. Now if these worker processes are separate why would this be? Can more than one request be processed on a single worker thread at the same time? This is tremendously important as there are unique ID’s that are held in these static members to handle escalation of the objects that manage these functions and it appears that they are trying to access the same object.

I’m running this on Vista’s IIS server on an x64 machine.

EDIT

For values that need to persist through the thread on a single request, I put these values into Web.HttpContext.Current.Items which seems to do the trick.

<ThreadStatic()> can be used but it may not be available during the entirity of the request process. In one module that I have, is only used on a variable to indicate if that thread has already loaded the settings for the cahcing server. If true then the tread (not asp.net) is ready to fetch data from the caching server.

Answer 1

First concept to change: if you’re using ASP.NET, they are ASP.NET threads, not IIS threads.

Second, this is a .NET issue. static variables are shared throughout the AppDomain in .NET. Since you’ll have one AppDomain per IIS application (more or less), that means your static variables will be shared across all worker threads in the application.

There will be a lot more than four threads, and they’ll all be sharing the same variables, which means you’ll either need to do locking, or you’ll need to not use static variables.

Whatever your understanding has always been, I suggest you go back and figure out where you got that understanding from; then update it, because it doesn’t have much to do with ASP.NET.

---

EDIT: The subject has changed, so I’ll change the answer a little.

You have to interlock access to these variables. Alternatively, you should consider reevaluating your design. Your design apparently assumed some different model for access to statics. This assumption has turned out not to be correct. It’s possible that this assumption may have cascaded throughout your design. You should reevaluate your design in the light of reality.