On 3/22/06, Julian Tillmann <[EMAIL PROTECTED]> 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" <[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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
