FormBeans stored in user's session... where's the performance?
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Anonymous
Posted On:   Wednesday, March 20, 2002 04:13 AM

I've been reading about how struts works, and the fact that it stores every form bean in the user's session has really caught my attention. Is this really necessary? Just imagine a large application with high user activity and a high number of forms. The server's memory would get used up in a snap. If I am wrong, please tell me WHEN struts decides to take these objects out of the user's session, because leaving them there seems very costly and unecessary to me. I think they should be put in the request scope, and be created and populated every time the user interacts with the form through an Action.    More>>

I've been reading about how struts works, and the fact that it stores every form bean in the user's session has really caught my attention.


Is this really necessary?


Just imagine a large application with high user activity and a high number of forms.


The server's memory would get used up in a snap.


If I am wrong, please tell me WHEN struts decides to take these objects out of the user's session, because leaving them there seems very costly and unecessary to me.


I think they should be put in the request scope, and be created and populated every time the user interacts with the form through an Action.

   <<Less

Re: FormBeans stored in user's session... where's the performance?

Posted By:   Christopher_Koenigsberg  
Posted On:   Wednesday, March 20, 2002 08:50 AM

I think the idea, the reason that the form bean is in the session rather than the request scope, is that a user may be interacting with the same form more than once, across multiple requests, in the same session.



Also a form bean can be used for the data of more than one form page, i.e. in a set of related forms, in a workflow or whatever, which would each come in their own request.



Disclaimer: Maybe someone else has already thought of this and has already implemented it and sells it, or has it for open source downloading somewhere..... but if not, hey give me some credit in your notes when you do it, :-)



It does sound like you have brought up something important, in design and support for scaleable Web applications, that perhaps where needed, control of server-side data (cached persistence) and expiration ought to be more fine-grained than just the choice of which scope to assign it to (the request, session, or application), and having it live or die equally with everything else in the chosen scope.

.

I could imagine a session manager servlet, for instance, which could read policy config files, or could be sent hint messages, and which would monitor the session scope state, maybe even in the (memory, performance etc.) context of the whole server-side JVM maybe, so you could do your own expiring of selected session data according to your own criteria.



Also I am thinking that recent computer science trends seem to be towards allowing flexible and more precise policy and hinting, on the API level, coupled with more intricate adaptive implementation internally.



That is how the overall Java Garbage Collection works, and I could imagine that a session object management system (or even a more general "scope object management system" for whatever scope, including application, session, request, tele-, peri-, or mouthwash) could work in a similar fashion (as another layer on top of the Garbage Collector).

About | Sitemap | Contact