tomcat-users mailing list archives

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


For non-specific Tomcat questions, it exists :
There's also an other one wich is JSP oriented.


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

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

Maybe someone knows better practice ?



----- Original Message -----
From: <>
To: <>
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
> web/servlet programming.  If anyone does know of one, could you let me
> 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
> object along without putting it in the session, I usually end up with
> more than a headache and 1 more attribute in my session.  :(  I'm
> 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
> way to get around this problem.  I would love it if there were an object
> a thisRequestAndTheNextOne object, where attributes would stick around for
> current request and subsequent request, and then the controller could get
> objects from the previous request and determine if it should put them in
> new thisRequestAndTheNextOne object for the current request.  I don't know
> that makes sense to anyone else, but, nevertheless, does anyone have any
> to do what I'm trying to do?
> Does anyone else feel my pain?  ;)
> Thanks,
> -Jeff
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message