Where to keep user's id?

Question

I am designing a web application which should keep the user's profile that has lots of information, obviously it reads the data from database.

Currently, I have the username in my session and everytime I need the user's info should read the session then create an object of profile class (that read the data from database again) to retrieve user's info, is it the best practice for such an issue?

Answer 1

Generally a 'best practice' is to maintain the User profile data in session and load all needed information only the first time from the database.

In other words mantain an instance of Profile class in your http session (must implement Serializable ). Profile must hold all the informations used more frequently .

Note that 'reading the session' is like reading an HashMap (so has a minimum cost in term of performances). When the HttpSession will expire, Profile will be garbage collected.

UPDATE (based on your comments) :

to count (or find) active users (inactive are all the others), a typical solution is make Profile implements the HttpSessionBindingListener interface. When Profile is bound to a session, is notified, so you can increment a static counter (a static attribute of Profile class for example),and you can decrement it when the Profile is unbound (programmatically unbound or because its session has expired)

Answer 2

This is a typical trade-of between performance and memory consumption. If you want a fast application, keep the whole user profile in HTTP session but make sure you have enough memory in your server.

If you want to keep resource consumption low, store only user ID in session and load it from a database every time you need it. This also makes clustering simpler as there is less data to migrate.

Reasonable compromise is to use the latter approach with some caching. This way hot users (currently using the system) are kept in memory, while idle users or infrequently accessing new pages are swept out from cache (assuming cache is smaller then the number of HTTP sessions).

Answer 3

Agreed with Obe6 response, Best practice is to ensure if the profile is not in session then to retreive from a datasource and then attach it to a session.

When session is invalidated then all information is removed from session. There is a good article on this from IBM. http://www.ibm.com/developerworks/websphere/library/bestpractices/store_objects_in_httpsession.html

Answer 4

Session is generally a good enough place to keep the user profile data. You need to quantify how much of data you are talking here. Let's say its 5KB per session, then, you could store up to 20000 user profile in memory using 100 MB of RAM. You can allocate heap to JVM accordingly based on the max. number of active sessions you expect on your site.

This is just one aspect. When you plan to scale the app by adding more app servers, then, you can even think of moving the sessions out to a out-of-process cache/memory stores such as memcached.

If all the user profile data you keep in session does not get rendered on each page, then, it may be a good idea only to keep bare minimum in session and fetch other data as per need.