Hi all, I want to know what are the objects that come into consideration while calculating the session size. Is it only the session objects(or session attributes) which have to be considered for calculating session size? If there are some other things plz lemme know.
I know I am being very dumb here but ..! Thanks & Regards, Ravi Kora [EMAIL PROTECTED] 337-739-3434(M) -----Original Message----- From: Jon.Ridgway [mailto:[EMAIL PROTECTED]] Sent: Friday, July 12, 2002 5:47 AM To: 'Struts Users Mailing List' Subject: RE: Problem with session ojects: memory size, updates Hi, Your English is a hell of a lot better than my French...Your question is one that comes up a lot on the list try a search at: http://www.mail-archive.com/[email protected] for 'session size'. One pertinent post is: http://www.mail-archive.com/[email protected]/msg34592.html In short, the answer to what should go in the session depends on how your application will be used. If you expect a *very* high number of concurrent users your session should be under 4k (taken from iAS, WebLogic and WebSphere docs, white papers etc). It will also depend on your hardware, how much RAM is available, network bandwidth, database size/speed etc. If you can predict the highest level of concurrent users, multiple your maximum session size by this. The result will be the amount of RAM taken up by all the sessions put together, if you have sufficient RAM to handle this and all over requirements, then the session size is not an issue. Note however that the number of users can explode unexpectedly, so the best practice recommendation is to keep session size as small as possible. As for the speed of looking up objects from the session, this will depend on your app server, when clustering some app servers will store the session in a db or other persistent store, lookups in this case are relatively expensive. If you are not clustering, I wouldn't worry about the speed of the lookup (even if you are I wouldn't worry about it that much - its not a bottle neck I've ever come across.) Jon Ridgway -----Original Message----- From: Heligon Sandra [mailto:[EMAIL PROTECTED]] Sent: 11 July 2002 15:12 To: '[EMAIL PROTECTED]' Subject: Problem with session ojects: memory size, updates Sorry, my english level isn't very good. I read that the Struts framework doesn't make (oblige) to use one particular model implementation (EJB, JavaDataObject, JavaBean, ...). But the JavaBean solution is understood or greatly recommended, isn't it ? Because struts uses JSP to display data and JSP pages use JavaBean tags. If we work whit XML representations of remote business objects, is it better to use struts XSL tags rather than generate JavaBean from the XML description ? The XSL solution requires to know XSL tags and is slower and more complex. With JavaBean solution I am frightened having memory or request time problem. The user does a request, the selected Action gets business data from the enterprise tier, generates one or several JavaBean instances and stores the JavaBean in the HttpSession. But the HttpSession size will grow quickly. It is difficult to know when we have to store data in request scope or session scope. Has somebody advices about this dilemma? I am tending to put data systematically in HttpSession in order to reduce network traffic if the user ask again this page. What is the max size of the session objects ? If we user rights on the business objects, we will have the same JavaBean in several HttpSessions. What do you think about this problem ? A last question if we have numerous session objects, when we will have to update one of them it will be very slow to find it in the list. Do you have advices about that ? Is the JavaBean/HttpSession solution realistic with "real-time" data? Thanks a lot in advance. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> The contents of this email are intended only for the named addressees and may contain confidential and/or privileged material. If received in error please contact UPCO on +44 (0) 113 201 0600 and then delete the entire e-mail from your system. Unauthorised review, distribution, disclosure or other use of this information could constitute a breach of confidence. Your co-operation in this matter is greatly appreciated. -- 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]>
