Home/ Questions/Q 8694081
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T00:41:55+00:00

I’ve read storing information in Session State is bad idea for scalability but is

  • 0

I’ve read storing information in Session State is bad idea for scalability but is it ok if the Session State is stored in SQL rather than in Proc?

Typically when a user logs in I assign their customerID to a session variable which is used on pretty much every page to filter the information for them. What is the best approach to storing this customerID if it is not in a Session Variable.

I can use the User.Identity.Name field to go and query the database to get the customerID but I don’t see any difference in that and storing the session variable in SQL. Also is there a way I can just extend the User.Identity class to include a CustomerID variable? Again I don’t see how this would be any better than just storing a session variable.

Any thoughts very welcome!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Yes, you can do all of those things. Storing things in Session is discouraged for several reasons, not just for scalability. One reason is that the session times out, gut the user may still be logged in. You can always check if the variable is null and repopulate it, but you would have to do that on every page, or create some helper method you would have to call form every page.

    SQL Sessions are a lot slower, and require a database lookup for every request. So that’s one reason to avoid them.

    You can lookup the ID in something like a global action filter, but again, this causes a database lookup for every request.

    Another option is to extend the IIdentity interface (which is what the User.Identity object is) to add the CustomerID. There are various examples out there if you google “IIdentity MVC”

    • 0