or check out http://java.sun.com/blueprints/patterns/j2ee_patterns/value_object/
Dave --- Dave Hodson MessageCast, inc. Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www.messagecast.net > -----Original Message----- > From: Manish_Purang [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 15, 2002 10:31 PM > To: Struts Users Mailing List > Subject: RE: Problem with session ojects: memory size, updates > > > hi, > > Maybe you could take a look at any of the ejb or java bean > design pattern > books to get an exhaustive idea about the value objects ..! > you can download > one free pdf version from the serverisde.com-- (Ejb Design > patterns by Floyd > Marinescu ) > > Rgds > > -----Original Message----- > From: Heligon Sandra [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 16, 2002 10:52 AM > To: 'Struts Users Mailing List' > Subject: RE: Problem with session ojects: memory size, updates > > > Perhaps my question is stupid but I am not sure to know the > Value object > notion well. > Could you give more details about Value Objects? > What is the difference between JavaBean and ValueObject(or > Data Transfer > Object also I believe)? > Value objects are shared by the web and the back-end tier. > > Thanks > Sandra > > -----Original Message----- > From: Dave Hodson [mailto:[EMAIL PROTECTED]] > Sent: 16 July 2002 00:38 > To: Struts Users Mailing List > Subject: RE: Problem with session ojects: memory size, updates > > > 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]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > ************************************************************** > ************ > This email (including any attachments) is intended for the > sole use of the > intended recipient/s and may contain material that is CONFIDENTIAL AND > PRIVATE COMPANY INFORMATION. Any review or reliance by others > or copying or > distribution or forwarding of any or all of the contents in > this message is > STRICTLY PROHIBITED. If you are not the intended recipient, > please contact > the sender by email and delete all copies; your cooperation > in this regard > is 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]>
