I would say it depends. How expensive is a database hit and how many times do you find the need to hit the database to retrieve data? Is all the data used all the time or is just some of the data used? In your application is it acceptible to have a slight delay while loading the users profile? Is the users profile subject to change by other entities/system during their session? (can the data become stale?)
These are some questions you need to ask yourself which will help determine your course of action. If it is acceptible to load all 30 attributes at logon AND the data does not have a chance of becoming stale AND you have the memory to accomodate it, then I would choose solution 1. Of course, if the user edits their profile, you will have to synchronize it with the database. If just some (a small portion) of the user's data is necessary, then I may choose a lazy loading scheme. robert > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 26, 2002 9:20 AM > To: [EMAIL PROTECTED] > Subject: what to store in session? > > > Consider following situation. > > User is logging into web application. What to store in session? > > 1. User object - it can be a large one (about 30 attributes, Strings, > associated Objects). In this situation will be only one request to > database (on user logon). Then all data will be taken from this object. > > 2. Put in session only user unique identifier (key) and then load > neccessary data from database only when it's requested. > > Which one is better approach? > > md > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
