This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi, 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 Jim
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.
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
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 Dave.
Joined: Nov 22, 2001
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 topic..as this is urgent required. Thanks
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: SomeServlet SomeServletLogin 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. *Whoa* 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?
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.
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.
Bosun (SCJP, SCWCD)
So much trouble in the world -- Bob Marley
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?
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 ]