ASP.Net provides 5 locations to store your application data:
Session and ViewState get used quite a bit by Asp.Net developers. Application and Cache probably get used the next most often and Context is probably the least used by developers. Here is a quick review and basic of these in app storage mechanisms.
Important: there are other storage mechanism also available for your consideration, like: Cookies, QueryStrings, HiddenFields, etc. These are all storage mechanisms available to all web-applications. I am discussing only Asp.net specific options here. Also on the server side – there is the option to store data to databases, etc. Again – this post discusses mechanism for storing short lived data – data that isnt required across application life-times.
Scope: Available across all sessions, i.e., to the entire application (caveat: it is available to all sessions running on the same server).
Lifetime: Application. Data is lost when the application shuts down.
Considerations: When inserting data – you must do so in a thread safe manner.
Scope: Available to only the current user session
Lifetime: Session. When the session expires the data is lost. Important to realize that InProc session-state is available only on the server that processed the request. Other types available that persist data to a database or xml, that allow the session state data to be available across servers.
Considerations: Need to be aware of memory load your session data might be putting on your web-server. If sessions are long running and data is large – you potentially run the risk of your application running out of memory.
Scope: Available to only the current user
Lifetime: Page. Provides a mechanism to store information to the page – so that the data is available across multiple requests to the same page.
Considerations: The other options discussed on this page are all server side options. ViewState is a client-side data storage option. Important to be aware that storing data to the view state will increase the size of the page that is sent to the user’s browser (as its stored in a hidden-field on the page). This will lead to longer trip times (server to client and client to server). As data is sent to the user – security is a consideration: data could be viewed by user or could be modified. View State can be encrypted and validated to work around these issues. Never use View State to store anything that should not be viewed by the end-user, even if you are using encryption and validation.
Scope: Available to the entire application, i.e., across all sessions
Lifetime: Volatile and non-deterministic. Data removed according to expiration policies set when adding data to Cache or when .Net determines memory is running low for that application.
Considerations: Never assume data that was saved to the cache will be available later. Always check for null value. Cache stores data using weak references – allowing it to discard the data when expiration occurs or when memory loads dictate it.
I love the cache – because it takes on the responsibility of handling timers and when to discard data stored within it. I typically use the session key appended to the key name to store session specific data to the cache – taking advantage of the Cache’s cleanup capabilities. (If you do go down this route, it is important to make use of Session_OnStart and Session_OnEnd events to clean up the cache – so that data is not inadvertently shared between users when session ids are reused). Another option is to use a “UserId” from your database (if you have one), to store user specific data to the Cache – this way you do not have to worry about problems arising from reuse of SessionIds.
Also, a little known fact is that even though the Cache object is found in the System.Web namespace, the Cache object is available for you to use even in your WebForms applications.
Asp.Net State Management Options: http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx