File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes object storing in session or request Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "object storing in session or request" Watch "object storing in session or request" New topic

object storing in session or request

james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Pls suggest,i am storing vectors currently,in session (in vectors i am storing results from the database)and from servlet i forward the request to jsp page there i am getting vector from session.
Can any suggest here which one is better to use from performance and memory wise means a) to store objects in session or b) store objects in request.
Pls suggest

Mark Elliott

Joined: Jan 15, 2002
Posts: 6
It really depends on how long you want objects to hang about. If you really only want then for the length of the request then use request scope if they need to live for the length of the session then session.
Also from the sounds of what you are doing a bean might be a better way to store the information (although this doesn't affect the debate on scope). But then again you may have your own reasons for doing it as you have.
Kyle Brown
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
Well, the request has a much shorter lifetime. Basically, the request object is garbage-collected at the end of the originating servlet's service() method. The Session, on the other hand, is held in memory until the session expires (when the user logs out, or when the session timeout occurs). For that reason, it is best to put almost everything that is needed to populate your JSP pages in the request. Only things that really and truly need to be held across multiple HTTP request/reponse pairs (servlet invocations) should be held in the Session.
For instance, if you show the User's name or account number on every page, hold it on the session. However, if you're fetching back data from a database to display on a single page, put it in the request.

Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at for other WebSphere information.
David O'Meara

Joined: Mar 06, 2001
Posts: 13459

My "rule-o-thumb" is to only place objects on the session that are true for the life of the session. Therefore it isn't the place for error messages, search results, or stuff that should obviously be placed on the request...
Also understand that I'm a bit of a hadr-line case. I'm against putting anything on the session unless you are prepared to argue about it
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
thanks for the information.
In java is there is any way where i can check which object is taking how much memory.Like in windows takemanager,we have processes,that shows this process is taking this much CPU.
similarly if i want to do this in java for object how can i do this ........?
Waiting for some help on above this is urgent required.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Yes, there is.

If you can prevent yourself from giggling, you can use perfanal.

I haven't heard of this being used with servlets, but it can give you a pretty good idea of how much time is spent in what parts of your code.
David O'Meara

Joined: Mar 06, 2001
Posts: 13459

Originally posted by Mike Curwen:
If you can prevent yourself from giggling...

Um, apparently not
Matt Horton
Ranch Hand

Joined: Feb 06, 2002
Posts: 107
My "rule-o-thumb" is to only place objects on the session that are true for the life of the session. Therefore it isn't the place for error messages, search results, or stuff that should obviously be placed on the request...

Now that I have incurred the 'mary mother of god what have I done' heart flutter, let me diagram my application:
Two servlets:
A user visits SomeServlet, depending upon login status, they are redirected to SomeServletLogin.
Upon authentication, SomeServlet instantiates an application, and places it into the session object...
That application's front door (there are no more servlets through the life of this application) acts as an intermediary, intercepting the content type of the request. If we're dealing w/ multipart/form-data, I'm importing, otherwise enumerate the request's parameters and break them up into a Hashtable.
And submit the hashtable to the underlying page manager (elsewhere on import but you still get the idea).
The page manager knows where the user is in the application, and it submits the incoming information to its assistant managers that take the user through the task (I believe you and I talked about this application before David but perhaps I didn't discuss my app's flaws in detail ). These assistant managers maintain their individual containers (or pages) that depending upon the status of the incoming hashtable, determine state. Requests include (the application is a worksheet app, including some jdo):
1) build a worksheet
2) add/edit/delete a record
3) save/cancel (on edit of course)
4) download a file
5) import a file
6) email info
7) yadda yadda yadda
Again: these individual containers reside in their respective managers that reside in a main manager, which reside in an application that reside in the session object. And there's the crux.
Each user has a sizable application sitting on their session object, but at the time I was at a loss on how to better manage user state.
So in short, it would be relatively easy for me to break many of these elements out into separate servlets (probably not jsp right now, b/c I've so screwed myself I don't know if I can incur an additional learning curve ). However, after changing:
a) initial application (front door, my 'SomeSession' that I put on their session) to a servlet (cool, no state issue)
b) the initial page manager to a servlet (no state issue)
c) the individual asst. managers to a servlet (no state issue)
d) this is where I hit the muddle. If I can get all the way here I'll feel like the day/weekend was a good one.
But, and this is a big but (everyone I know has a big but, Simone let's talk about your big but), those pages have a bit of state to them per user. My thought had been to let a user switch from one worksheet to another worksheet and back, w/o having to reinstantiate the recordsets. I'm starting to realize that that's not a core requirement for the application (as an aside, were it a requirement, ideas?) but I'm still hesitant about the switch... these pages all just return strings, but they do hold collections (whose select had top * luckily) per user.
Ideas? Thrasing? (thrash constructively).
Should I have a beer at lunch?
Kaustubh Patil
Ranch Hand

Joined: Aug 13, 2001
Posts: 164
I don't think u can put ur objects in the request..request only takes the form fields in the html .
So you can put your objects in the session. But be sure to remove them after u are over with them. So save your performance.

Kaustubh. Mumbai, India.
Bosun Bello
Ranch Hand

Joined: Nov 06, 2000
Posts: 1510
kaustubh, objects can be added to the request just likeobjects can be added to the session. Actually the method names are the same get/setAttribute etc. It's just that the object in the request is only available for the lifetime of the request. i.e Attributes are reset between each request, as explained in the other posts.

So much trouble in the world -- Bob Marley
Roger Graff
Ranch Hand

Joined: May 29, 2001
Posts: 112
I'm dealing with the same issue using a Model 2 pattern with JSP's. I'm building a questionaire application that has 5 pages of questions (about the user) and a sixth page that outputs advice based on the user's answers on pages 1-5. The user is able to move back to a previous page to change their answers, so I need to store their answers. Each page is a seperate JSP, so if I store their answers in the request, the data will be lost as soon as the next JSP is displayed. So, my only alteritive is storing the data in the session. I've basicly planning on have one User object in the session with 50-100 data members. I am concerned with storing this much data in the session. What happens when 100-200 users are using the application?
Shubhrajit Chatterjee
Ranch Hand

Joined: Aug 23, 2001
Posts: 356
It all depends on your application server and machine capability.
If you can allocate your server about 128M of memory and keep your session objects lean, then you should face no problem.
For example say about 75% of the heap memory is available to your application and you have about 200 user sessions at a time, You can create about 450K of session objects per user session.
Do a capacity planning and some R&D with your application server to get to the actual figures as the figures we have quoted is quite off hand.
[ June 03, 2002: Message edited by: Shubhrajit Chatterjee ]

I agree. Here's the link:
subject: object storing in session or request
jQuery in Action, 3rd edition