tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikola Milutinovic" <Nikola.Milutino...@ev.co.yu>
Subject Re: howto avoid overuse of session object?
Date Fri, 02 Aug 2002 05:24:35 GMT
> Thanks, C├ędric and Peter Lin, for your responses.  Both of you seem to be
> saying that, instead of storing large objects in the session object, I should
> be storing them in the application object (ServletContext).

ServletContext is not application context (yes, there is an application context, too). If
you need objects saved between requests, during one session then session has to have enough
information to save the state. If you're not going to pack all the state in the current session
(I'm not sure why is this a bad idea), then your other option is to pack that some place else
and just store some ID in the session.

Whether you're packing single beans in hierarchically "higher" contexts or you place them
into a database (via JDBC) or create EJB (an overkill and misuse, I'm sure), you still end
up saving that information somewhere. So, somewhere it will fill up memory, buffers, disk,
whatever. I cannot fathom why it is better to load piles of objects into higher contexts and
have to worry about identifying them and cleaning up after expired sessions, than having them
in session context.

> I find this to be
> rather confusing.  It seems like the overhead involved in storing things in
> the application object would be much greater than storing things in the
> session object.

Same here.

> At least the session objects would eventually die when
> ssions time out or they are invalidated by the web app, and the space they
> re using could then be garbage collected.  But the application objects would
> live as long as the server is up, and I would think would eventually consume
> memory moreso than using the session would.

You would have to implement session cleanup via some Listener (SessionListener or some such
class). Basically, you'd be emulating something like "dispersed session context", with parts
of a particular session held elsewhere. Ugly, nasty, not to mention slow. IMHO.

> Also, there would be a extra
> level of complexity involved with maintaining the association between the
> objects in the application object and their respective sessions.  Am I unclear
> on the concept, or is there something else that I'm not understanding?

Would someone enlighten us. Why is session context so dreadful that we should avoid it? I
agree we should minimize it's use, but minimization is not avoiding the use.

Nix.
Mime
View raw message