struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Lowe" <mel...@gmail.com>
Subject Re: Strategy for Controlling the Session Size
Date Wed, 22 Mar 2006 20:47:30 GMT
On 3/22/06, Michael Jouravlev <jmikus@gmail.com> wrote:
> On 3/22/06, Mark Lowe <melowe@gmail.com> wrote:
> > On 3/22/06, Michael Jouravlev <jmikus@gmail.com> wrote:
> > > On 3/22/06, Mark Lowe <melowe@gmail.com> wrote:
> > > > For data you need to store across lots of requests, you can create a
> > > > simple javaclass to hold the data you need. Something like a StateBean
> > > > or even a hashmap, the point is that if you have one object that your
> > > > storing things in you know where to look if and when you find you need
> > > > to address session size. If you have folk adding the world into the
> > > > session all over the place, its going to be harder to address any
> > > > issues later in the day. e.g. Map state = (Map)
> > > > session.getAttribute("state")
> > >
> > > Such holder class is already provided by Struts for every action. It
> > > is called ActionForm ;) I stick all my action-related... I mean,
> > > webresource-related :) stuff into corresponding ActionForm.
> >
> > If its the from you want in the session, you wont hear any arguements
> > from me there. But its also possible that the data you need to store
> > isn't really a form, you may need to populate a form with some session
> > scoped data (yes it could well be an action form). You may want to
> > reset a form but not the session scoped gubbins. One example i can
> > think of is maintaining the state of a gui, selected items and such
> > like. I never have a real need to have this data mapped to an action.
>
> This data is not mapped to an action, it belongs to a web resource. An
> action (or several actions) handle requests to a web resource, while
> ActionForm holds state of a web resorce. Instead of fixating on
> actions try to concentrate on an ActionForm ;)

Its not a fixation, and like I said I have sympathies with using an
action form for this. But recently I had to get someone up and started
with struts comming in from the cold, and quirks like this can confuse
folk. Albeit a rumination I think that a session scoped form needs
mapping to an action to be initially instantiated.

 If Struts had Action
> and ActionForm as one class, things would be easier.
>
> I don't care that ActionForm was originally intended to hold request
> values. I use it as a web resource state holder and stick all kind of
> resource-related stuff into it. Works great for me, all in one place,
> accessible. I can also make use of Struts automatic population of
> nested properties.

Population of indexed properties is a nice gift, but then I cant think
of many situations where needing to scope anything that extreme is
required. A bean with simple properties will do

<jsp:useBean id="state" class="foobar.State" scope="session" />
<jsp:setProperty name="state" property="*" />

takes care of any simple properties, and if you dont like doing this
stuff in jsps then in the execute method of a base action will do just
as well. If stuff works for you then thats great, but while I believe
using session when something else cant be done in a clear and readable
way.

I just dont see the point in giving a container a bad day when it
needs to serialize these objects, the same way as i dont think bending
over backwards to avoid using the session is worth it either.

Another consideration is the increased popularity of xmlhttprequest to
have the client make requests, if a front end updates from the server
at any intervals. All you need is are users leaving a browser window
open to increase the amount of active sessions on the container. Of
course something that listens where there are any events on the active
window could log the user out in his/her absence, but already its less
simple than just timeout configuation.

Again, I'm not disagreeing with you, in some situations I can see what
you're saying being clean and low risk, I just dont think all the
time.

Mark

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

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


Mime
View raw message