ASP.NET Storing global variables - accessible from every page

I am building a large application and I ususally use a simple session to store private global information however as the application could be rather large I belive this could be a problem due to the amount of memory sessions it could have.

Is there a better way to store such variables?

For example, when the user logs in I want to store data about that user and display it where needed without having to query the database each time.

From stackoverflow

• use cookies - they would work irrespective of your load balance environments

  other options include:

  1) writing your sessionvalues to a sql database - you can configure your asp.net app to configure session state to use sql server - but this has its own problems as sessions never time out (so u need to handle this via code explicitly)

  2) if not using sql server - basically you would face a problem when you have too many users and you implement load balancing on your web server - so a user can go to a different web server in the same session (and it would not work)

  there is a work around for this too - its called STICKY SESSIONS - where your web server guarantees your user would always hit the same web server within the session

  3) with .net 2.0 provider model, you can even write your own session storage provider by implementing their delegates - so you can create your own xml files on your web server / shared server to read / write session data there :-)

  so there are many ways you can solve this. however the simplest and cost effective solution is to use cookies

• You might use Cache. That has built-in mechanism to free up when memory is running out...

  annakata : and doesn't depend on client cookie settings

• If you think your data is too large for the Session, I would consider a database of some sort using cache so that you don't unnecessary calls.

• If it is per-user-session data you're storing, using the ASP.NET Session is definitely your best bet. If you're most worried about memory usage then you can use MSSQL mode. The data has to live somewhere and the choice of which session mode to use is dependent on your environment and the usage patterns of your users.

• Don't assume there will be a problem with the size of session state until you see such a problem and have tried to solve it. For instance, it's possible that, although the application as a whole may use a large amount of session state, that any given user may not use that much in the course of a session.

  I's also possible that changing from the default session state provider to the SQL provider or state server provider would ease a memory issue.

  You can use Cache, but Cache is application-wide. You would need to qualify Cache entries with the user id or session id: Cache[userID + ".MyCacheEntry"].

  Do not, under any circumstances, use static variables to store this data. As suggested by your subject line, they are application-wide, not per-user.

• Sessions are the way to go here, they are intended to persist information about the current session across requests. There is no other object in the ASP.NET framework that has this intention.

  You could use the Cache, or store in the Application collection, but then the responsibility of uniquely identifying the individual session data is up to you.

  What's also up to you is handling when the session terminates, and freeing up the instances that are stored in those collections (Cache or Application).

  It's really a bad idea to start to ask these questions based on what you might "think" will happen. This is a form of premature optimization, and you should avoid it. Rather, use Sessions, as they were intended for this purpose, then measure where your bottlenecks are and address them, should performance be an issue when testing.

• Definitely use cookies for this. The best approach is to make yourself a cookies wrapper class that will do all the heavy lifting for you - checking if cookie is null, accessing the httpcontext, etc. No need to mess up your code with all that; just abstract it all out into cookies.cs or .vb.

  SetCookieValue(someValue, cookieName); //there will be some expiration concerns here as well
  
  myValue = GetCookieValue(cookieName);
  

  Christian Weiss has a good strategy.