tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Viaud <cedric.vi...@matrasi-tls.fr>
Subject Re: howto avoid overuse of session object?
Date Thu, 01 Aug 2002 16:30:01 GMT
Hi,

FIRST

For non-specific Tomcat questions, it exists :
SERVLET-INTEREST@JAVA.SUN.COM
There's also an other one wich is JSP oriented.

SECOND

All best practice i know says that you must minimize the ammount of data
stored in the session. So, the traditional approach of this problem is to
only store the user-id (simple type) in the session. All over session
informations (a class containing all required informations) are stored in
the servlet context.

Praticaly, on the request you get the user id from the user session. Next
you use this Id to get the "user information obect" from the servlet
context.

This is certainly deceiving, but this is the way ...

Maybe someone knows better practice ?

Regards,

    Cédric

----- Original Message -----
From: <jeff.guttadauro@abbott.com>
To: <tomcat-user@jakarta.apache.org>
Sent: Thursday, August 01, 2002 6:13 PM
Subject: OT: howto avoid overuse of session object?


> This is sort of off-topic, but I don't know of a better forum targeting
Java
> web/servlet programming.  If anyone does know of one, could you let me
know?
>
> I'm basically wondering if others have found effective ways to avoid the
> tempting but bad practice of loading up the session with all sorts of
> attributes.  I often find myself needing some Bean or other object for
maybe 2
> or 3 requests, and, rack my brains as I may for an elegant way of passing
the
> object along without putting it in the session, I usually end up with
nothing
> more than a headache and 1 more attribute in my session.  :(  I'm
developing
> with an MVC approach, with Struts for more recently developed apps and a
> similar custom framework for our older apps, but I just can't seem to see
a
> way to get around this problem.  I would love it if there were an object
like
> a thisRequestAndTheNextOne object, where attributes would stick around for
the
> current request and subsequent request, and then the controller could get
> objects from the previous request and determine if it should put them in
the
> new thisRequestAndTheNextOne object for the current request.  I don't know
if
> that makes sense to anyone else, but, nevertheless, does anyone have any
ideas
> to do what I'm trying to do?
>
> Does anyone else feel my pain?  ;)
>
> Thanks,
> -Jeff
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message