Store user information in session?

Question

Should you store info about the user required for each request eg. Role, email, username etc.

in Session, or is ok to goto the database each request for this information??

Thanks

Answer 1

I prefer to use an encrypted cookie for this. The db calls can get expensive in large, busy systems. Session is fine, but if your session backend is database powered, that can get expensive too. Obviously, when using cookies, you have to incorporate an authentication token check.

Answer 2

I would not store in session, which flying over the net with each request, anything which can be read from database.

Big session object could become real issue in long time -- it's so easy to add one more think to it :).

Answer 3

That depends on what you mean by "Should". I've worked on a few apps that used the session for caching user information. The approach worked well and reduced the amount of database round trips required for each web request.

On the other hand, it does introduce state to your web servers so you either have to stick to one web server, use "sicky sessions" (which can make managing web servers a bit more complicated) or start storing session information in a shared data store (which wipes out any performance gain you might have had from using it in the first place).

Answer 4

Session data can be stored in the database as well, which is usefull if your site is running in a Web Garden og Farm. If the session is running InProc, the user data will be saved in memory, which is of much cause faster, but at the cost of scalability.

Another common way would be to save it as ViewState, then it is sent back and fourth between the client and server with every postback, which of cause courses a bandwidth hit, but scales much better that the InProc session.

Personally I like session state better, if the site is small I run it InProc, and if/when the site grows I can change it to use a Database instead.

Answer 5

If you're not planning on load balancing, then session state is perfectly acceptable. Be careful if the session state is configured to use database persistence though, because then you'll not only be hitting the database, but incurring an overhead of serialisation of the objects.

If it's user-specific data, then a distributed hashtable cache system might work. Things like Memcached are good for this, because they are in-memory caches (performance) but are distributed across multiple servers (load balancing) so you get the best of both worlds.

Of course, if it's data that changes regularly, particularly if you other systems that might modify the database without the web app knowing, then going back to the database might be the only option.

Answer 6

I keep the userid in Session and I keep the active user records in Cache for many of my applications, but then again I tend to keep the contents of all of my dropdown lists in Cache, and I have to present a dropdown of users every now and then.

I've had a number of people exclaim "OMG you keep that in Cache!?!?" but actually, it works great. Better that I have exactly one copy of the user list in Cache than one copy per application instance (100 concurrent users means potentially 100 copies of the user list in memory). In general I put anything that doesn't change frequently in Cache, and force it out of Cache if it does change, so it will reload on next access.

Answer 7

It depends on your site/app. The general rules are something like this:

Saving in the session works well if the number of simultaneous users is fairly low and the the data is relatively small.

Saving in a cookie works well if the number of simultaneous users is high and the size of the data is relatively low. Obviously cookies are publicly viewable so if it is sensitive such as email then it should be encrypted.

Saving in the database works well if the size of the data is large.

Note. As others have said if your using a web farm then I would forget about saving in the session.

Martin Fowler has a good description of the options in 'Patterns of Enterprise Application Architecture' but I'm not sure if he has stuff online.

If the site/app requires authentication then .Net has good built in functionality for storing user roles and unique user names. If you save this during the authentication then these values can be accessed through User.IsInRole() and User.Identity.Name.

Is storing in the session causing you performance problems? If the size of your data is relatively small such as email then I would go with using the session or cookies and avoid the database. Run performance tests and see what performs best for you.