struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Hodson" <d...@messagecast.net>
Subject RE: Problem with session ojects: memory size, updates
Date Wed, 17 Jul 2002 22:35:56 GMT
or check out

http://java.sun.com/blueprints/patterns/j2ee_patterns/value_object/

Dave

---
Dave Hodson 
MessageCast, inc.
Email: dave@messagecast.net <mailto:dave@messagecast.net> 
www.messagecast.net


> -----Original Message-----
> From: Manish_Purang [mailto:Manish_Purang@satyam.com]
> 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:Sandra.Heligon@nextream.fr]
> 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:dave@messagecast.net]
> 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: dave@messagecast.net <mailto:dave@messagecast.net> 
> www.messagecast.net
> 
> 
> > -----Original Message-----
> > From: Jesse Alexander (KADA 11) [mailto:alexander.jesse@csfs.com]
> > 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:Sandra.Heligon@nextream.fr]
> > 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:Jon.Ridgway@upco.co.uk]
> > 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:Sandra.Heligon@nextream.fr] 
> > Sent: 11 July 2002 15:12
> > To: 'struts-user@jakarta.apache.org'
> > 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:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-user-help@jakarta.apache.org>
> > 
> > 
> > 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:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-user-help@jakarta.apache.org>
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
> > <mailto:struts-user-help@jakarta.apache.org>
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
> > <mailto:struts-user-help@jakarta.apache.org>
> > 
> > 
> 
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
> **************************************************************
> ************ 
> 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:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:struts-user-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message