-----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 11:31 AM To: Struts Users Mailing List Subject: Re: what to store in session? On Wed, 26 Jun 2002, [EMAIL PROTECTED] wrote: > Date: Wed, 26 Jun 2002 15:19:48 +0200 > From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > 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? > I don't think there is a universal answer to "better", but here are the rules of thumb I use: * Do not store anything in the session that is either needed only once, or can be retrieved so quickly that it does not affect response time in any material way. * Do not store complete data structures that are large and complex, unless they really represent shared application data (in which case they should probably be in the servlet context attributes instead). * Hide the caching choice you are making inside the get methods of your user object, so you can change your mind later without modifying all the code that uses the data. As an example of the latter approach, let's say that you have a Permissions object associated with the user, which is made available through a getPermissions() method on the User object that is stored in the session. You can implement getPermissions() at least three different ways: * Load the permissions data every time it is requested ("no caching"). * Load the permissions data when the user object is created ("always caching"). * Load the permissions data the first time it is requested (if ever) and use the cached copy for repeated requests ("lazy instantiation"). But the important principle is that all the code that needs permissions should just call user.getPermissions() -- without knowing how the caching is done (if any), the application logic does not have to change. Now, you can (for example) create your user object initially with the "no caching" approach, and modify it during performance tuning if you notice that the repeated database access is a hotspot. > md > Craig -- 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]>
