Forums Register Login
setting attributes to session vs. to request
What are the advantages of setting attributes to session versus to the request?
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...
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?
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.
thanks for clearing that up
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.
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.
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,
Doody calls. I would really rather that it didn't. Comfort me wise and sterile tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database

This thread has been viewed 1124 times.

All times above are in ranch (not your local) time.
The current ranch time is
Jan 18, 2019 14:01:46.