As I said in my original email: You could try to map every process exit and remove
unneeded
objects at then end of a process; however, implementing this might be burdensome in a
complex
application.
Suggestion #2 fro QM makes this point and adds clarification: "Obviously a "process"
in this case
may span several requests; so, like good code, you'll have to account for removing the
object even
in the event the process short-circuits (e.g. when the user hits an error page instead
of reaching
the proper ending). Unlike good code, you don't have a handy "finally{}" clause... =)"
The tricky part is, cleaning up after a multi-request process terminates because the
process could
terminate in unexpected ways (someone simply abandons the process by clicking another
link, etc.).
Here is what I think might be a pragmatic solution within a Struts framework:
Assume we are building a CRM application and we are creating the process that enters
customer
contacts. The first page of the process is contactEntryOne.jsp. The page is
displayed by
clicking a link that is mapped to DisplayContactEntryAction.java (an action class that
simply
forwards to contactEntryOne.jsp).
A submit button on contactEntryOne.jsp is mapped to ProcessContactEntryOne.java, an
action class
that does some processing, stores some objects in the session and then sends the user
to another
JSP which has another submit button mapped to ProcessContactEntryTwo.java, and so on.
The process
ends with a call to DisplayContactEnteredAction.java (which may simply forward to a
success page).
By convention, we could agree that all processes begin and end with a call to an
action class that
begins with "Display...": DisplayContactEntryAction.java , and
DisplayContactEnteredAction.java.
We could also agree that all intermediate processes are done by a call to an action
class that
begins with "Process..."
If we assume that once a process ends or a new process begins, all the session objects
for the old
process are invalid, life becomes simple :). In every "Display..." action class
(which may begin
or end a process or just display a single page) we can make a call to a utility method
that clears
the session of all objects except a predetermined set.
The overhead of making a call to a session cleanup utility method would be marginal
compared to
the increase in system efficiency.
Please note, the degradation in performance due to session objects is not just a
matter of system
speed and memory. You reach a point in a complex system where the number of objects
chokes the
JVM's garbage collector. Buying a faster system with more memory will help, but
writing good code
might be a better solution
What are your thoughts on the merits of this solution?
Mike
--- QM <[EMAIL PROTECTED]> wrote:
> On Sat, May 29, 2004 at 11:31:26AM -0700, Mike Duffy wrote:
> : I asked these question in the Struts list and only received a minimal response:
> Does anyone
> have
> : any good ideas on managing session objects? In a complex application how do you
> insure that
> the
> : session does not become over burdened with unnecessary objects, thus degrading
> system
> performance?
>
> In no particular order:
>
> 1/ Use the Request object when you can; use the Session when you must.
> (Paraphrasing a line I hear a lot in the C++ world...)
> If you don't put something in the session, it certainly can't
> stick around and take up space.
>
> 2/ Make sure each process that puts an object in the session is
> designed to remove it. Obviously a "process" in this case may
> span several requests; so, like good code, you'll have to
> account for removing the object even in the event the process
> short-circuits (e.g. when the user hits an error page instead
> of reaching the proper ending). Unlike good code, you don't
> have a handy "finally{}" clause... =)
>
> 3/ Load-test your app and size memory accordingly. Even with the
> best-laid cleanup plans, people will close browsers without
> formally logging out, etc. You simply have to deal with this
> and make sure your app has enough heap space to handle the number
> of concurrent users. Size per your worst-case scenario.
>
> 1 and 2 are coding practices, and must be enforced by the architect (by
> explaining to the developers). This takes place before and during
> development.
>
> 3 is an architectural issue, addressed during development and after a
> good portion of the app has come to life.
>
>
> ps - please create a new message when mailing the list. Responding to
> an old (unrelated) message plays hell with thread-aware mailers, even if
> you change the subject. Thank you.
>
> -QM
>
> --
>
> software -- http://www.brandxdev.net
> tech news -- http://www.RoarNetworX.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
