Caching Database Data in Session - Getting Balance
If you cache data from your database in an ASP.NET session, you will speed up subsequent requests for that data (note: depending on the serialization / deserialization of the data cost) by loading memory in IIS.
(OK, this is probably a simplification of the reality of the situation - feel free to correct or refine my statement above)
Are you using any rules (simple rules of thumb or others) to decide when to cache in a session?
Update
It is possible to use a session for read - only storage without a very thoughtful rationale just to be considered another case Premature optimization ? (and therefore bad)
source to share
Remember that when caching in a session, if you are using InProc mode, you are limiting scalability if your code does not return to the DB when the session is empty. You will be forced to use one server or bind your user to a specific server.
If your session state server does not apply, and if using SQL to store session state, then using session for caching is pointless.
Edit
Any advice on this topic depends on your specific environment. As you stated, a very complex SQL query can be useful in caching even when using SQL session state. I think the most important thing is to make your application run first and meet the business requirements. Then go back and test and optimize the application to handle the expected load.
Edit 2
Based on your update, I don't think this is true. In one of my ASP.Net applications, I use session state to store a complex object model that the user manipulates and modifies. We are using AJAX and therefore we have a lot of short communication with the server as the user updates the object. Storing an object during a session was done as a belief. The object does a lot of custom computations to create different data points, so doing this on the server was perfect, rather than trying to replicate code in servo mechanics and javascript. In addition, in-session storage allows us to easily override the feature.
And I know we sacrificed scalability, but I welcome the day that I sit down with my boss and explain that we have a problem because we have too many users (and I know he does too).
So I think the question is why are you storing data in session, is it for convenience and to provide access to temporary data during user login? This is different than storing it there for caching. One thing to remember when caching is how are you going to clear the cache? How do you make it invalid? I am not creating a session state to handle this.
Edit 3
It only reads well user specific data, expensive to load from DB, keep caching it in session. You can write your code so that if it's not in the session, you end up in the DB. Have a nice little helper class that does this while avoiding it from your web app that you are even using a session and you should be nice. The good thing about where you store it from your network is, if you find yourself in trouble, you only have one place to change it.
source to share
Given that it is very difficult to guarantee that the data in the session is cleared in a reasonable amount of time, I would be very careful about cashing in anything larger than an odd integer. When you go large, you will either run into memory issues or all of your users will have session timeout errors. Remember, unlike sessions, Cache objects are not discarded when memory is low.
Also, as Josh says, if you are migrating to multiple servers and must use either a database or a session state server, your session object must be consistent. In this case, the cost of serialization and serialization is likely to be worse than the cost of a well-optimized query.
source to share