struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Pilgrim" <peter.pilg...@db.com>
Subject Re: Request / Session Scoped Beans, Best Practices
Date Fri, 28 Sep 2001 10:21:10 GMT


Well you could any, some  or all of the following

1) Use a caching mechanism, a flyweight container that stops people
create simultaneous objects of the same value for every single user session.

2) Built your own "sub" scope container. Put this is the session. For example
you may create a set of form beans for the sub "ordering" scope and
the another a set of form beans for the sub "analysis" scope.
Once you move from the "ordering" part of the web app to "analysis"
(and vice versa) grab your sub scope container and ask it delete
all its elements in a tidy fashion.

3) Have some your own naming convention "orderXXXXBean"
and "analysisXXXXBean" in the session. It is a simple to write
an Action base classes that implements a __GUARD__ pattern.
Your guardians will watch the session scope and implement
beans because it match all session object for say "analysis*Bean"
(String.startsWith("analysis") and String.endsWith("Bean") )
that don't belong where there should be.

I would favour number (2) sub scope containers put in the session.
Write a full container that fires binding session events so that
you can have object listen and respond to clean up.

HTH

--
Peter Pilgrim          |  |        ++44 (0)207-545-9923
            .... \  \  ___   /  / ... .
            -   ----  ( * )  ---   --
_____________________________Cafe_Savannah,_San Antonio,Ibiza__



---------------------------------------- Message History ----------------------------------------


From: "Molitor, Stephen" <SMolitor@erac.com> on 27/09/2001 18:07 EST

Please respond to struts-user@jakarta.apache.org

To:   "'struts-user@jakarta.apache.org'" <struts-user@jakarta.apache.org>
cc:   "Talyan, Vivek" <VTalyan@erac.com>; "Hohlen, John" <JHohlen@erac.com>; "Nekkalapudi,
Viplava" <VNekkalapudi@erac.com>
Subject:  Request / Session Scoped Beans,  Best Practices


Hi.  We've been using Struts for a few weeks now, and we're looking for
advice on when to use session versus request scoped objects.  So far, our
policy has been to use request scoped objects by default, except when that's
not convenient.  If we find that we need to remember the same ActionForm or
read-only value bean on more than one page, we stick it in session scope.
We have a lot of session scoped objects.  However, we're worried that this
won't scale very well.  We understand that session scoped objects are
totally appropriate for many cases; we just feel that we are over using
them, and need a better way to manage them.

First there's the memory issue -- as our app gets bigger, we will have more
and more session scoped objects lying around.  We can use
HttpSession.removeAttribute to clean up objects we no longer need, but it
can be tricky to make sure that all paths lead back to the removeAttribute
call.

More important is the maintenance and name clash issue.  For ActionForms, we
avoid having two forms with the same name, since they're all specified in
the struts config file, and it won't allow us to define two forms with the
same name.  That's great.  However, for read-only value beans, we have just
been hard-coding the attribute names in the Actions and JSP pages.  A year
from now, a new developer might be working on a new piece of the app, and
accidentally pick the same name as an older session scoped value bean,
stomping on the older bean.  Session attribute names are like global
variables (global to one user, anyway), and seem to have all the problems
associated with global variables.  So, how do people manage them?  A
constants file/interface?  What about naming conventions?  We've been using

--<CUT>--




--

This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.



Mime
View raw message