Hi Sandra, Value-Objects are less than an EJB.
Value-Objects are just "data-transporting objects". They contain only attributes (obviously with setter- and getter-), but no other methods. EJB's have a whole lot of additional functionality in them. VO's are (usually) easily serializable. hope this helps Alexander -----Original Message----- From: Heligon Sandra [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 16. Juli 2002 17:37 To: 'Struts Users Mailing List' Subject: RE: Problem with session ojects: memory size, updates I read Value Object pattern on J2EE design pattern http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html. I understood that JavaBean are an implementation of ValueObjects. "a value object represents a business object, but it doesn't need to provide business methods on top of its data; it only provides methods to read its data, which makes it an ideal candidate for local access rather than remote access." So I don't understand your remark "Another possible solution is to create Value Objects and serialize them". Did you want to say that EJB is a solution? Because we don't want to work with EJB. In my architecture I get data from an enterprise back-end system and then Action class create Value Objects(JavaBean) if the object required doesn't exist. If I need to update data on the back-end server, then a manager is in charge of serializing and sending JavaBean across the Network. But to maintain user information (JavaBeans) over multiple requests and pass data between Action and JSP I need to store ValueObject in a cache(session or request scope). Could you detail please why ValueObejct serialization can be a solution to session size growth ? Thanks a lot in advance -----Original Message----- From: Manish_Purang [mailto:[EMAIL PROTECTED]] Sent: 16 July 2002 07:31 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/struts-user@jakarta.apache.org/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/struts-user@jakarta.apache.org > > for 'session size'. One pertinent post is: > > http://www.mail-archive.com/struts-user@jakarta.apache.org/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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
