You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Kamholz, Keith (corp-staff) USX" <kk...@moog.com> on 2002/07/17 19:33:45 UTC

Objects In Session

Hey all,
I know that putting lots of objects in the session is a bad idea and is very
frowned upon.  However, it's much much easier than using request objects.
If I put an object in the session temporarily, for a process or two, then
remove it from the session as soon as I'm done with it, is it still bad
practice?  What are the drawbacks to this?

~ Keith
http://www.buffalo.edu/~kkamholz


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Objects In Session

Posted by Joseph Barefoot <jo...@hereuare.com>.
Well, you have to make sure you are cleaning up your session objects as soon
as you are through with them, as you already noted.

One drawback to session objects is that user behavior is unpredictable.  For
instance, if a user initiates step one of a 3-step process, a session object
is created to hold the data, but then if the user clicks on something else
entirely, the session object will still be there although the process is
broken.  Ordinarily you would clean it up at the conclusion of the process,
but since the user aborted, you have no *easy* way to do it.  There are ways
you can 'lock' a user into a process and force them to cancel before any
other request will be processed, but they are not very straightforward.


peace,
Joie

> -----Original Message-----
> From: Kamholz, Keith (corp-staff) USX [mailto:kkamholz@moog.com]
> Sent: Wednesday, July 17, 2002 10:34 AM
> To: Struts (E-mail)
> Subject: Objects In Session
>
>
> Hey all,
> I know that putting lots of objects in the session is a bad idea
> and is very
> frowned upon.  However, it's much much easier than using request objects.
> If I put an object in the session temporarily, for a process or two, then
> remove it from the session as soon as I'm done with it, is it still bad
> practice?  What are the drawbacks to this?
>
> ~ Keith
> http://www.buffalo.edu/~kkamholz
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>