aspose file tools*
The moose likes Servlets and the fly likes setting attributes to session vs. to request Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "setting attributes to session vs. to request" Watch "setting attributes to session vs. to request" New topic
Author

setting attributes to session vs. to request

Olivia Mayo
Greenhorn

Joined: May 11, 2003
Posts: 29
What are the advantages of setting attributes to session versus to the request?
maneesh subherwal
Ranch Hand

Joined: Aug 26, 2002
Posts: 42
Basically setting an attribute to a request can only be accessed by the request whereas the session attribute can be accessed between multiple requests. A good example would be a shopping cart - the users shopping items could be stored in the session. Within this application, if a form needs to be submitted (e.g. you have a page that requests user comments) could be accessed using a request attribute.
hope this helps...
Maneesh


Sun Certified Java Programmer 2 (1.4)<br />Sun Certified Web Component Developer
Olivia Mayo
Greenhorn

Joined: May 11, 2003
Posts: 29
thanks for the reply but i just got confused with a comment made by a colleague. she said that as much as possible she refrains from saving objects to the request and she uses the session instead. isn't that more taxing on the performance of a system?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61010
    
  65

Since attributes tacked onto a session will remain there until removed or the session expires, care needs to be taken that stale attributes don't "build up". Other than controlling the lifetime of the attributes, they are no more taxing on the system than any other Java objects.
bear


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Olivia Mayo
Greenhorn

Joined: May 11, 2003
Posts: 29
thanks for clearing that up
maneesh subherwal
Ranch Hand

Joined: Aug 26, 2002
Posts: 42
I usually look at this very closely since I am under the impression too that session objects are expensive to handle for the web server. I have tried to find more information on how vendors (IBM, for one) handles the session objects so that I have a clearer idea about how they are stored and how expensive the session data actually is but to no avail.
Moreover, as Bear mentioned, the stale objects always seem to be an issue and if a session is not invalidated explicitly by the user, the data hangs around until the session timeout value is exceeded.
I usually clean up the session objects once I know, for sure, that I will not need them anymore and also create them if and only if I need the value on multiple pages.
Also, another question that may be helpful would be: Is the overhead the same for storing this object in the session the same as the overhead for creating a new object and storing it into the request everytime a request is made? I believe if there a multiple uses for the same object value, the value should be stored in the session.
Thanks,
Maneesh
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

Making a decision purely on memory is the wrong way to go. This is an important issue to keep in mind when using session data, but shouldn't be the first factor considered when putting information on the session.
The first question is: should the data be on the session?
It's not an easy one to answer, but my general rule is that data should only be storred on the session if it is valid for the life of the session. Regardless of the page the user visits, is the data valid?
Shopping carts are acceptable, since the data in the cart may vary, but the cart itself is valid for the life of the session and the data should be valid on any page that the user visits.
I've seen developers place exception flags and messages on the session with the assumption that it will be detected and handled on the next page, and this is the sort of thing I don't like at all. It isn't thread-safe, and it assumes the client won't do things like have two browsers open or hit the back button half way though sending the request.
I tend to have a bit of a strict approach to session usage, but just try to keep in mind what it's meant for rather than just putting everything there just because it's convenient. It's similar to having all data stored in global variables - it makes code easier to write, but harder to maintain.
Dave
maneesh subherwal
Ranch Hand

Joined: Aug 26, 2002
Posts: 42
I agree with everything that has been said here: putting values in the session that do not really need to be there is a no-no and no one should usually do that. Of course memory management is important and that also goes back to the fact that the session should not contain irrelevant information.
Thank you,
Maneesh
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: setting attributes to session vs. to request