You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Julian Tillmann <pu...@gmx.de> on 2006/03/22 10:04:04 UTC
Strategy for Controlling the Session Size
Hi
Can someone give me advice how to control and clean
the amount of Collections (HashTables/ArrayList)
that are stored in the session.
My first consideration goes in the direction to
use a naming-strategy for all lists to be used in a session
(eg session.setAttribute("collection_name",
and always when an action is executed
to look
for all parameters if session.getAttribute.equals("collection_name
and to remove all last Action's Collection_data in order to minimalize my
session data.
Regarding to you, does it make sense to control the session-size
within a struts application this way.
Thanks a lot for your opinion!!
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for Controlling the Session Size
Posted by Rick Reumann <st...@reumann.net>.
Julian Tillmann wrote the following on 3/22/2006 4:04 AM:
> Can someone give me advice how to control and clean
>
> the amount of Collections (HashTables/ArrayList)
>
> that are stored in the session.
Are you actually sure you have a performance problem with too much stuff
stored in Session scope? Sometimes people seem to freak out when there
isn't even an issue.
Also, I'm sure you have a reasonable time-out set for each user's
session correct?
--
Rick
http://www.learntechnology.net
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for Controlling the Session Size
Posted by Mark Lowe <me...@gmail.com>.
On 3/22/06, Julian Tillmann <pu...@gmx.de> wrote:
> Hi
> Thank you for your answer!
>
> Basically we have to save
> collections in the session because
> we use displaytag and both the export-function
> and the sort function requires the lists
> to be safed in session.
well the choice is to use session scope, or you could keep things in
the request and create you own comparators to sort the list as you
like on each request. I dont know enough about display tag's export to
have any opinions.
> I think a kind of pool cannot solve the problem
> because of that.
> This listener sounds very interesting I'll
> take a look.
This was more as a means of monitoring session usage in general. Can
be handy if you're walking into an app where some jokers been sticking
stuff in the session without a second thought.
> As a last resort would my proposal be an
> acceptable alternative?
Will depend on how many users you need to support and restrictions
that clustering might bring. At the end of the day if you do things in
a clean way, you'll always know where to fix the problem should one
occur.
If you do go the session scoped route you could use a servlet filter
to clean up as soon as a request not related to sorting and exporting
your collection is made. A simple session cleaning filter that you
configure to ignore the url's where you need the collection to be in
the session, else session.removeAttribute("yourcollection")..
<filter>
<filter-name>cleanerFilter</filter-name>
<filter-class>foobar.SessionCleanerFilter</filter-class>
<init-param>
<param-name>ignorelist</param-name>
<param-value>/sort.do,/export.do</param>
</init-param>
</filter>
<filter-mapping>
<filter-name> cleanerFilter </filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>
...
private String[] ingorelist;
public void init(FilterConfig config) throws ServletException {
this.ignorelist = config.getInitParam("ignorelist").split(",");
}
public void doFilter(...) throws ServletException {
//check url if is to be cleaned or not
if(!ignored) session.removeAttribute("collectionname");
chain.doFilter(..);
}
HTH
Mark
>
> greetings
>
> > --- Ursprüngliche Nachricht ---
> > Von: "Mark Lowe" <me...@gmail.com>
> > An: "Struts Users Mailing List" <us...@struts.apache.org>
> > Betreff: Re: Strategy for Controlling the Session Size
> > Datum: Wed, 22 Mar 2006 11:34:31 +0100
> >
> > On 3/22/06, Julian Tillmann <pu...@gmx.de> wrote:
> > > Hi
> > >
> > > Can someone give me advice how to control and clean
> > >
> > > the amount of Collections (HashTables/ArrayList)
> > >
> > > that are stored in the session.
> >
> > If you do find you need collections stored in httpsession, i wouldn't
> > use hashtable.
> >
> > >
> > > My first consideration goes in the direction to
> > >
> > > use a naming-strategy for all lists to be used in a session
> > >
> > > (eg session.setAttribute("collection_name",
> > >
> > > and always when an action is executed
> > >
> > > to look
> > >
> > > for all parameters if session.getAttribute.equals("collection_name
> > >
> > > and to remove all last Action's Collection_data in order to minimalize
> > my
> > >
> > > session data.
> > >
> > >
> > >
> > > Regarding to you, does it make sense to control the session-size
> > >
> > > within a struts application this way.
> >
> > The size of the session can effect clustering, and is also expensive
> > in a standalone envionment. But that aside it becomes harder to
> > maintain applications when developers are using session at each and
> > every oppertunity. You can use a session attribute listener to see
> > where things are being added, but life is generally easier if session
> > is used as little as possible. I recently worked on some legacy apps
> > where session had been used over liberally and performance issues
> > aside you couldn't work out what the state the application was in.
> >
> > 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")
> >
> > Your post will probably provoke some fanaticism claiming "sessions are
> > evil" , "never use sessions" and such like. IMO you want to use it as
> > little as possible, and when you do know where its been used.
> >
> > I guess the question is, what are you thinking of putting in your session?
> >
> > Mark
> >
> > >
> > >
> > >
> > > Thanks a lot for your opinion!!
> > >
> > > --
> > > "Feel free" mit GMX FreeMail!
> > > Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
> > >
> > > --
> > > "Feel free" mit GMX FreeMail!
> > > Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
> --
> Echte DSL-Flatrate dauerhaft für 0,- Euro*!
> "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
>
> ---------------------------------------------------------------------
> 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
Re: Strategy for Controlling the Session Size
Posted by Julian Tillmann <pu...@gmx.de>.
Hi
Thank you for your answer!
Basically we have to save
collections in the session because
we use displaytag and both the export-function
and the sort function requires the lists
to be safed in session.
I think a kind of pool cannot solve the problem
because of that.
This listener sounds very interesting I'll
take a look.
As a last resort would my proposal be an
acceptable alternative?
greetings
> --- Ursprüngliche Nachricht ---
> Von: "Mark Lowe" <me...@gmail.com>
> An: "Struts Users Mailing List" <us...@struts.apache.org>
> Betreff: Re: Strategy for Controlling the Session Size
> Datum: Wed, 22 Mar 2006 11:34:31 +0100
>
> On 3/22/06, Julian Tillmann <pu...@gmx.de> wrote:
> > Hi
> >
> > Can someone give me advice how to control and clean
> >
> > the amount of Collections (HashTables/ArrayList)
> >
> > that are stored in the session.
>
> If you do find you need collections stored in httpsession, i wouldn't
> use hashtable.
>
> >
> > My first consideration goes in the direction to
> >
> > use a naming-strategy for all lists to be used in a session
> >
> > (eg session.setAttribute("collection_name",
> >
> > and always when an action is executed
> >
> > to look
> >
> > for all parameters if session.getAttribute.equals("collection_name
> >
> > and to remove all last Action's Collection_data in order to minimalize
> my
> >
> > session data.
> >
> >
> >
> > Regarding to you, does it make sense to control the session-size
> >
> > within a struts application this way.
>
> The size of the session can effect clustering, and is also expensive
> in a standalone envionment. But that aside it becomes harder to
> maintain applications when developers are using session at each and
> every oppertunity. You can use a session attribute listener to see
> where things are being added, but life is generally easier if session
> is used as little as possible. I recently worked on some legacy apps
> where session had been used over liberally and performance issues
> aside you couldn't work out what the state the application was in.
>
> 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")
>
> Your post will probably provoke some fanaticism claiming "sessions are
> evil" , "never use sessions" and such like. IMO you want to use it as
> little as possible, and when you do know where its been used.
>
> I guess the question is, what are you thinking of putting in your session?
>
> Mark
>
> >
> >
> >
> > Thanks a lot for your opinion!!
> >
> > --
> > "Feel free" mit GMX FreeMail!
> > Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
> >
> > --
> > "Feel free" mit GMX FreeMail!
> > Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
> >
> > ---------------------------------------------------------------------
> > 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
>
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for Controlling the Session Size
Posted by Julian Tillmann <pu...@gmx.de>.
thanks for all your ideas and advice especially the one with the filter was
very helpful. :)
ciao 4 now
Julian
> --- Ursprüngliche Nachricht ---
> Von: "Mark Lowe" <me...@gmail.com>
> An: "Struts Users Mailing List" <us...@struts.apache.org>
> Betreff: Re: Strategy for Controlling the Session Size
> Datum: Wed, 22 Mar 2006 23:56:20 +0100
>
> On 3/22/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > On 3/22/06, Mark Lowe <me...@gmail.com> wrote:
> > > 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
> >
> > I don't want to argue with you either :) I use session-scoped
> > actionforms, so it is simpler for me to stick everything related to a
> > resource in an actionform.
> >
> > > 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.
> >
> > I don't use Ajax autoupdate. But even if I did I would use session to
> > store Ajax-related stuff. Otherwise when a user hits Reload button,
> > all stuff is gone. Check out Backbase Pet Shop demo. Apparently these
> > guys don't use session. Pet Shop is a demo, but I would not want to
> > lose my shopping cart because of accidental refresh.
>
> Yeah, i'd store ajax related requests the same as I would for non ajax
> requests as well.. And better an actionform than having n amount of
> attributes that are hard to keep track of. Cant say i see the value in
> a ajax shopping cart but interesting link.
>
> >
> > 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
>
--
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for Controlling the Session Size
Posted by Mark Lowe <me...@gmail.com>.
On 3/22/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 3/22/06, Mark Lowe <me...@gmail.com> wrote:
> > 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
>
> I don't want to argue with you either :) I use session-scoped
> actionforms, so it is simpler for me to stick everything related to a
> resource in an actionform.
>
> > 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.
>
> I don't use Ajax autoupdate. But even if I did I would use session to
> store Ajax-related stuff. Otherwise when a user hits Reload button,
> all stuff is gone. Check out Backbase Pet Shop demo. Apparently these
> guys don't use session. Pet Shop is a demo, but I would not want to
> lose my shopping cart because of accidental refresh.
Yeah, i'd store ajax related requests the same as I would for non ajax
requests as well.. And better an actionform than having n amount of
attributes that are hard to keep track of. Cant say i see the value in
a ajax shopping cart but interesting link.
>
> 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
Re: Strategy for Controlling the Session Size
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/22/06, Mark Lowe <me...@gmail.com> wrote:
> 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
I don't want to argue with you either :) I use session-scoped
actionforms, so it is simpler for me to stick everything related to a
resource in an actionform.
> 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.
I don't use Ajax autoupdate. But even if I did I would use session to
store Ajax-related stuff. Otherwise when a user hits Reload button,
all stuff is gone. Check out Backbase Pet Shop demo. Apparently these
guys don't use session. Pet Shop is a demo, but I would not want to
lose my shopping cart because of accidental refresh.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for Controlling the Session Size
Posted by Mark Lowe <me...@gmail.com>.
On 3/22/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 3/22/06, Mark Lowe <me...@gmail.com> wrote:
> > On 3/22/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > > On 3/22/06, Mark Lowe <me...@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
Re: Strategy for Controlling the Session Size
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/22/06, Mark Lowe <me...@gmail.com> wrote:
> On 3/22/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > On 3/22/06, Mark Lowe <me...@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 ;) 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.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for Controlling the Session Size
Posted by Mark Lowe <me...@gmail.com>.
On 3/22/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 3/22/06, Mark Lowe <me...@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.
But I'm going off topic now..
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
Re: Strategy for Controlling the Session Size
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/22/06, Mark Lowe <me...@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.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for Controlling the Session Size
Posted by Mark Lowe <me...@gmail.com>.
On 3/22/06, Julian Tillmann <pu...@gmx.de> wrote:
> Hi
>
> Can someone give me advice how to control and clean
>
> the amount of Collections (HashTables/ArrayList)
>
> that are stored in the session.
If you do find you need collections stored in httpsession, i wouldn't
use hashtable.
>
> My first consideration goes in the direction to
>
> use a naming-strategy for all lists to be used in a session
>
> (eg session.setAttribute("collection_name",
>
> and always when an action is executed
>
> to look
>
> for all parameters if session.getAttribute.equals("collection_name
>
> and to remove all last Action's Collection_data in order to minimalize my
>
> session data.
>
>
>
> Regarding to you, does it make sense to control the session-size
>
> within a struts application this way.
The size of the session can effect clustering, and is also expensive
in a standalone envionment. But that aside it becomes harder to
maintain applications when developers are using session at each and
every oppertunity. You can use a session attribute listener to see
where things are being added, but life is generally easier if session
is used as little as possible. I recently worked on some legacy apps
where session had been used over liberally and performance issues
aside you couldn't work out what the state the application was in.
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")
Your post will probably provoke some fanaticism claiming "sessions are
evil" , "never use sessions" and such like. IMO you want to use it as
little as possible, and when you do know where its been used.
I guess the question is, what are you thinking of putting in your session?
Mark
>
>
>
> Thanks a lot for your opinion!!
>
> --
> "Feel free" mit GMX FreeMail!
> Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
>
> --
> "Feel free" mit GMX FreeMail!
> Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
>
> ---------------------------------------------------------------------
> 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