Re: session and request scope
Radu. To avoid such problems you may use contextes. When you have contextes stored in the session and you store your values only in this context you have no problem to clean the session. There is a small architecture project called struts-it (struts-it.org) in detail http://plstrutsit.sourceforge.net/architecture/presentation.html, provides such a context. The signature of an execute-method is such as public void execute(Context context); where a context is a commons-chain context. The Request processor has the responsibility to create such contextes and share them over an use-case. This approuch is available for struts 1.2 as well as struts 1.1. I think the struts-chain (1.3) has the same approuch. Dealing witch contextes is quite nice, because you can use this context in the business layer too. Manfred Radu Badita wrote: At 08:14 14.03.2005, Craig McClanahan wrote: For a developer, though, you should train yourself to good habits in the first place -- use request scope for *everything* unless it absolutely must be saved, on the server side, in between requests from the same user. This sounds like common-sense but is only feasible in theory; that's because in non-trivial web-apps almost all the interactions are some kind of a dialog spanning multiple requests with the user and inevitably require session-stored data between request. Cleaning such data when the "dialog" ends becomes a pain. I hope that the "Dialog Controller" in the forecoming Shale will address this problem and provide the means for a "dialog-local session" that will automatically be released once the dialog completes. Furthermore, once a user is in the middle of such a pageflow, it shouldn't be possible to leave (requesting another dialog sequence) until the current one finishes. I've once worked with a home-made web framework which implemented such behavior (like a state machine) where the entire application was divided into states (each having a corresponding view), each state could have transitions (a transition executing an action) to other states or to another sub-application. Each "state machine" had it's own separate session which was removed on execution end. Between state-machines parameters could be sent by-value copying from one session to the other. All this was specified in an external xml doc. Too bad it was lacking a system for automating request and session parameters retrieval (like the ActionForms in Struts). That is the behavior that I would personally like in Shale, because I think it allows for much better design and reuse. Radu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- === Dipl.-Inf. Manfred Wolff Software Engineer --- http://www.manfred-wolff.de http://www.struts-it.org --- den. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session and request scope
At 08:14 14.03.2005, Craig McClanahan wrote: For a developer, though, you should train yourself to good habits in the first place -- use request scope for *everything* unless it absolutely must be saved, on the server side, in between requests from the same user. This sounds like common-sense but is only feasible in theory; that's because in non-trivial web-apps almost all the interactions are some kind of a dialog spanning multiple requests with the user and inevitably require session-stored data between request. Cleaning such data when the "dialog" ends becomes a pain. I hope that the "Dialog Controller" in the forecoming Shale will address this problem and provide the means for a "dialog-local session" that will automatically be released once the dialog completes. Furthermore, once a user is in the middle of such a pageflow, it shouldn't be possible to leave (requesting another dialog sequence) until the current one finishes. I've once worked with a home-made web framework which implemented such behavior (like a state machine) where the entire application was divided into states (each having a corresponding view), each state could have transitions (a transition executing an action) to other states or to another sub-application. Each "state machine" had it's own separate session which was removed on execution end. Between state-machines parameters could be sent by-value copying from one session to the other. All this was specified in an external xml doc. Too bad it was lacking a system for automating request and session parameters retrieval (like the ActionForms in Struts). That is the behavior that I would personally like in Shale, because I think it allows for much better design and reuse. Radu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session and request scope
On Thu, 10 Mar 2005 23:56:08 +0100, Günther Wieser <[EMAIL PROTECTED]> wrote: > as long as you don't have a clustered environment or session persistence > enabled in your servlet container, there shouldn't be much difference in > adding an object to a session or request. That is almost, but not quite, accurate. The physical act of storing and retrieving the object into request scope or session scope can have a minor performance difference (in request scope, the container doesn't have to synchronize because it knows only one thread is accessing the underlying HashMap). The more important issue, though, is that session scope attributes will occupy memory space in between HTTP requests (request scope attributes become eligible for garbage collection as soon as the request completes) -- that's fine if you need the underlying information, but flagrantly wasteful if you do not. On apps with lots of users, this can become a mission critical issue. For a developer, though, you should train yourself to good habits in the first place -- use request scope for *everything* unless it absolutely must be saved, on the server side, in between requests from the same user. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session and request scope
thank you all for the elaborate explaination! --- Günther Wieser <[EMAIL PROTECTED]> wrote: > as long as you don't have a clustered environment or > session persistence > enabled in your servlet container, there shouldn't > be much difference in > adding an object to a session or request. > > but it doesn't make sense to put it in session scope > if you don't use it is > session scope, but only in request scope. this could > make your life harder > than you want it to be (e.g. if you forget to delete > such objects). > > this leads to one issue for session scope: if you > store things in session, > you HAVE TO REMOVE them as soon as you don't need > them anymore, otherwise > you can run out of memory because these objects > won't be garbage collected. > and usually it's very hard to make sure that your > web app DEFINITELY reaches > the point of deleting things from a session (think > about a user just > pressing back or going to a different page before > hitting your "remove" > page). of course, everything will be dumped when the > session expires, but if > you have a lot of users in your web app and they > stay for a long time, the > memory consuption can become significant if you have > a lot of session > objects. > > kr, > guenther > > -Original Message- > From: wo_shi_ni_ba_ba > [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 10, 2005 10:52 PM > To: user@struts.apache.org > Subject: session and request scope > > In terms of performance, does storing an attribute > into the session cost > more than storing it into the request? how > significant is the overhead? > > > > __ > Do you Yahoo!? > Yahoo! Small Business - Try our new resources site! > http://smallbusiness.yahoo.com/resources/ > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session and request scope
as long as you don't have a clustered environment or session persistence enabled in your servlet container, there shouldn't be much difference in adding an object to a session or request. but it doesn't make sense to put it in session scope if you don't use it is session scope, but only in request scope. this could make your life harder than you want it to be (e.g. if you forget to delete such objects). this leads to one issue for session scope: if you store things in session, you HAVE TO REMOVE them as soon as you don't need them anymore, otherwise you can run out of memory because these objects won't be garbage collected. and usually it's very hard to make sure that your web app DEFINITELY reaches the point of deleting things from a session (think about a user just pressing back or going to a different page before hitting your "remove" page). of course, everything will be dumped when the session expires, but if you have a lot of users in your web app and they stay for a long time, the memory consuption can become significant if you have a lot of session objects. kr, guenther -Original Message- From: wo_shi_ni_ba_ba [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 10:52 PM To: user@struts.apache.org Subject: session and request scope In terms of performance, does storing an attribute into the session cost more than storing it into the request? how significant is the overhead? __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session and request scope
No, it's all memory. But, you have to remember that session attributes stay in memory for the life of the session (which typically spans many requests and perhaps all day long), whereas request attributes stay in memory for the life of the request. In other words, requests don't really require "cleanup", but sessions might. Lookup performance is the same; they are hash-based. Use request scope for items that are only needed to service the current request. Use session scope for items that are needed to service a particular user during the span of multiple requests. Use application scope for items that are needed to service any user at any given time (closest scope to being truly "static"). Erik wo_shi_ni_ba_ba wrote: In terms of performance, does storing an attribute into the session cost more than storing it into the request? how significant is the overhead? __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
session and request scope
In terms of performance, does storing an attribute into the session cost more than storing it into the request? how significant is the overhead? __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
