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.


Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 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.

Method 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…

Method 3

Another important difference, Session State will be blocked if concurrent async Ajax requests are executed, it will effect performance

Method 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.

Method 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.

Method 6

Session is per user, Cache is for the application.

Items in Cache can and will be removed automatically based upon expiration times (sliding or fixed) and memory constraints of the IIS worker process.

So basically items in Cache are never guaranteed to exist but Session will stay there until the session ends.

Storing items on a per-user basis (via Session or a creative use of Cache) can lead to a lot of memory usage and should be considered carefully.

On top of all of this, if IIS resets the worker process, you can lose your Cache and Session.

Method 7

See this answer.

Session can kill your app performance, unless you use some backend provider like memcached or velocity. Generally you should avoid it.

Method 8

As far as I know, it all depends on your needs.

Whenever you need to maintain state for the users, then you have to be very careful while using sessions. The default setting is ‘InProc’, which uses the individual server’s memory, does not work well in Cloud-based applications. This may be applicable for those of you who host your application in multi-instance web-farm environments. Windows Azure load balancer uses round-robin allocation within connected nodes.

You have multiple options in the session storage. SQL Server can also be used as a storage of session state. Custom session techniques are available on azure like table storage provider etc.

The Cache is also stored on the server’s memory, but it doesn’t have a concern with the users. Any user within the same pool can access the application cache data. In short, on the cloud, we need to use Caching service provided by the cloud providers. Azure provides Windows Azure distributed caching service.

As a matter of fact, developers do not care about the impact of state management techniques when applying the technique in the applications. It

“If your client doesn’t have cloud support, then you don’t worry about the cloud scenarios”

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x