Another possible solution is to create Value Objects and serialize them...
Dave --- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www.messagecast.net > -----Original Message----- > From: Jesse Alexander (KADA 11) [mailto:[EMAIL PROTECTED]] > Sent: Sunday, July 14, 2002 10:56 PM > To: Struts Users Mailing List > Subject: RE: Problem with session ojects: memory size, updates > > > Hi Sandra, > > I prefer to remove the objects from the session as soon as I can > declare that they are not usefull anymore. > EG.: In action_1 I build a model-object, use it in jsp_1 and > process the users action in action_2. If the usecase is finished here, > I remove the object from the session. > > As for session size: The 4kB recommendation comes from servers that > support clustering. Because the session must be propagated to all > members of the cluster, it should be kept as small as possible. > We have a few application running with substantial numbers of > concurrent > users that can have up several megabytes of session-data. If > the usecase > needs it, do it. Often we have the case that a few users need lots of > session data, and most users just a few bytes... > Ok for us session-data is used, because our persistance level is on a > CORBA-backend host and we have no jdbc on our midrange. Therefor we > calculate it is cheaper to a few Gig of memory to our servers in order > to save on network-data-transfer. > > hope this helps > Alexander > > -----Original Message----- > From: Heligon Sandra [mailto:[EMAIL PROTECTED]] > Sent: Freitag, 12. Juli 2002 13:11 > To: 'Struts Users Mailing List' > Subject: RE: Problem with session ojects: memory size, updates > Importance: High > > > Thanks John for your response, > > I have already read the message > http://www.mail-archive.com/[email protected]/msg > 34592.html > but I would like to have more details with real examples. > I believe that the best way is to try. > I read that objects in the session must be removed unlike the request > objects. > Is it good to do that when the application invalidates the session ?. > Because we save objects in the session in order to access > data during all > the session life. > > I would like to have advices or tricks for updating and > looking up session > objects (JavaBeans and not EJB). > Imagine I have the following business objects model: > > Class A composed of several instances B, each B item can be > composed of > several C instances. (nested beans). > If the list of each sub-beans is variable, must I use dynaBean ? > > Imagine the user make a request about the instance B2, I get data > information > and store the JavaBean B2 in the HttpSession. > Later the user makes an other request and the B4 instance is > required, I > store > B4 in the HttpSession. > > Then two problems: > 1. The last request needs to get A instance, I get A1 but > before saving A1 > I have to test if A1 is composed of B4 or/and B2 in order to > remove objects > from > the HttpSession. Then I store A1 in the HttpSession. > It is very complicated, isn't it? What are the others > solutions to store and > look up "nested beans" ? > > 2. The WebServer receives a data change notification, in this > case how can I > look up all active sessions and all session objects of each session to > update > the JavaBeans which changed? > How must I do to be sure that Actions or JSP pages don't > access data during > update? > > Thanks > Sandra > > -----Original Message----- > From: Jon.Ridgway [mailto:[EMAIL PROTECTED]] > Sent: 12 July 2002 11:47 > 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]/msg > 34592.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]> > > -- > 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]>
