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" <[EMAIL PROTECTED]>
> An: "Struts Users Mailing List" <user@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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
