Question

I’m using VS2010,C# to develop my ASP.NET web app, sometimes I need to declare public or even public static variable at start of my codebehind files, so that I can access them globally in the file and also they preserve their value between postbacks, everything works fine on my local server (as I’m the only person who runs the code). But I don’t know exactly what happens when this page (and therefor its codebehind) are run by several web site visitors at the same time, I want my program to run the same for all users, but I think in this way something will cause problems, I can remember from my previous ASP.NET experience that using variable (public or public static) in codebehind can cause misunderstanding for different users of web site, for instance:
user A runs program, (public static int) my_int that had the value of -1 at startup has taken value of 100, and at this time user B runs the same page, so my_int is 100 and it will cause problems, also suppose that user A leaves the page while my_int has value of 100, then user B will visit the page my_int would be initially 100 (while that should be -1) so I think unexpected behaviors would occur

is it right? will this happen at all? if so, how can I prevent it? should I use session instead of variables? how can I have a better understanding about the whole situation

thanks friends

Answer 1

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.