Advantages of Cache vs Session

Question

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.

Answer 1

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.

"If your client doesn't have cloud support, then you don't worry about the cloud scenarios"

Answer 2

I just came across another limitation that has given me a few issues in the latest .NET versions. That is with cache, you can store objects very simply. With sessions, you can only store strings.

Now, obviously, you can serialize your objects and store them as strings, but it is an extra step and I'm not so convinced that serialization always works the way you want it to. You have to ensure that your object is serializable. There are many examples of extension methods you can use to make it much easier.

But, with cache, it seems to just work. And being a lazy developer, I really don't want the extra hassle of serializing. There are also some significant differences between various serializers like Newtonsoft.Json and the new System.Text.Json. Although perhaps not relevant as you'll use the same Json serializer for both in and out.

With all the above answers, Cache seems like the safe bet, and if your application ever takes off and your server memory takes a knock, you can always use something like Redis to start handling that cache for you with very little effort.

Answer 3

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

Answer 4

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

Answer 5

See this answer.

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.