Advantages of Cache vs Session
What is the difference between storing a datatable in Session vs Cache? What are the advantages and disadvantages?
So, if it is a simple search page which returns result in a datatable and binds it to a gridview. If user 'a' searches and user 'b' searches, is it better to store it in Session since each user would most likely have different results or can I still store each of their searches in Cache or does that not make sense since there is only one cache. I guess basically what I am trying to say is that would the Cache be overwritten.
Solution 1:
One important difference is, that items in the cache can expire (will be removed from cache) after a specified amount of time. Items put into a session will stay there, until the session ends.
ASP.NET can also remove items from cache when the amount of available memory gets small.
Another difference: the session state can be kept external (state server, SQL server) and shared between several instances of your web app (for load balancing). This is not the case with the cache.
Besides of these differences (as others have noted): session is per user/session while cache is per application.
Solution 2:
AFAIK, The key difference is session is per user, while cache will be for application scoped items.
As noted in the other answers you can store per user info in the cache, providing you provide a key (either by session or cookie). Then you'd have more control to expire items in the cache and also set dependencies on them. So if the DataTable in question is going to change on a regular basis, then caching is probably an appropriate option. Otherwise, if it is static session might be more appropriate. Steven Smith has an excellent video on caching at dnrtv that is worth checking out.
It really depends on what you're trying to achieve, how much time you've got. There are some other alternatives to consider with respect to how you store state in an application. Depending on how large the table is, you could consider storing the state in a cookie (encrypted if it is sensitive information). Alternatively, if it's application scoped data you cold use a static field on a page or class. There is the Application object as well.
Update: I think the key question you have to ask yourself, is who should see this data.
Are they going to access the data frequently?
(No, don't bother).
Is it going to change?
(No, use a static field or Application).
Is it acceptable for user a and user b to see the same results?
(No, use the cache with a key comprising of the username and the search term.).
(Yes, use the cache using a key of the search term).
Honestly though, if you're not far along in your development, I would consider parking the caching/state issue to a later date - you might not even need it.
The first three rules of performance tuning are: 1. Measure, 2. Measure some more. 3. Measure again...
Solution 3:
Another important difference, Session State will be blocked if concurrent async Ajax requests are executed, it will effect performance
Solution 4:
Cache is in the Application scope with the purpose of reducing the number of times a piece of data is obtained. Session is in a user's session scope with the purpose of giving a particular user state.
Solution 5:
Well it depends on how you have session configured for ASP.NET. Are you storing session in a database or in memory? If in memory are you using a separate server or are you using the current webserver for session?
Depending on how things are set up for you there may be performance implications when you are using something like a datatable which tells me that you are perhaps storing large amounts of data.
Also Session is stored per user and is retrieved per user by means of their Session ticket that is stored either in a Session cookie or on the URL if they do not accept cookies and you have set up ASP.NET to cookieless mode. Anything that you cache will be cached at the application level and will be available to all user sessions which may or may not be what you want.