struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Wilson-Salt" <>
Subject RE: Struts and Sessions
Date Tue, 27 Jun 2000 12:07:28 GMT
I think you've covered the issues of resource use by sessions quite well.
However, there a just a couple of points that I can think of:

In my experience, coders are often slack about removing stuff from sessions,
so sessions tend to grow.

Also the correct use of sessions needs to be stressed, I feel they should
only be used for stuff that needs to held for a while. I feel that request
scope should be used for things which are only displayed on the resulting

This is why in my code I have always used Request scope for my equivalent of
Strut's ActionForm. Sure, a new form bean gets constructed everytime the
user iterates around the form, but most of the time users get it right first

I have to deal with devices that don't support cookies. But the usage
pattern on these devices tends to be a very short sequence of requests -
people looking for very specific information, rather than browsing.

If I want to support sessions on these devices, I have to resort to old
tricks like URL rewriting etc. Can Struts give me any help here, maybe
through its custom tags, to create URL rewritten links, and what should I do
about forms.

I know this has strayed away from Struts, and into more general servlet
programming issues. I hope people don't mind.

-----Original Message-----
From: Craig R. McClanahan []
Sent: 26 June 2000 18:58
Subject: Re: Struts and Sessions

Colin Wilson-Salt wrote:

> Would it be possible to make the use of sessions in Struts optional?
> I'm concerned about the resource overhead if we have a lot of people
visiting just a
> few pages in our site.
> We already build applications using the same kind of patterns that Struts
uses, but
> it would be nice to have the benefits of the formalised structure that
Struts gives.
> On the other hand, does anyone have any evidence that the resource
overhead of
> sessions is something I shouldn't be concernced about?

There are a couple of issues raised here (and in the follow-ups) to be

(1) Can I Use Struts Without Sessions?

Using the basic MVC controller servlet without sessions is certainly
feasible.  But it
is worth looking at what Struts uses sessions for, and therefore what you
give up
without them.

The background for this discussion is the fact that HTTP is a stateless
protocol.  In
other words, there is absolutely nothing provided by the protocol itself
that ties one
request from a particular user to the next request from that same user.
(Just as an
example, some people assume that they can use the remote IP address to make
distinction, but that doesn't work when your users are behind a firewall and
they all
appear to have the same IP address, or if you have multiple users running
off the same
server.)  The session management capability in the servlet API provides a
mechanism for
establishing this kind of connection between requests, and requires sending
the client
an identifier (using either cookies or URL rewriting) that the client can
send back on
the next request.

In Struts specifically, the following uses are made of sessions:

* You can store the ActionForm bean in the session or the request.
  If your bean supports multi-page input, session is the only way
  to save the values from the previous page(s).  For single page
  forms, request scope works fine.

* Struts expects a per-user Locale to represent the users's choice
  of language and display styles for internationalized messages.
  Generally, if this object is not present, the server's default Locale
  will be used.

In web applications based on servlets and JSP pages in general (including
those based on
Struts), you also have the following issues to think about:

* By default, JSP pages assume that they are part of a session.
  If you don't want this, you have to put the following code at the
  top of every single page:

    <%@ page ... session="false" ... %>

* Many applications perform their own authentication and login
  to make sure that only validated users can access certain
  parts of the application.  The usual mechanism for doing this is
  to store some sort of user object in the user's session -- if you
  detect that this object is missing (because the user tried to jump
  into the middle of your app without logging in, or because their
  previous session timed out), you force them to the login page.
  Without sessions, this will be very difficult to implement
  in a robust manner.

* Without sessions, you are limited to transactions that can be
  completed solely based on the request parameters of a single
  individual request, since you have no way to link more than one
  request together.

* Many sites like to personalize the appearance of their apps
  based on who the user is, or what preferences they have saved.
  Beyond the authentication issue mentioned earlier, most such
  apps save the user's current preferences in a session variable
  to save having to go back to the database every request.  This can
  be a significant performance impact.

So are sessions worth it?  Well, that depends on the cost, as we'll see in
the next
question ....

(2) What Are The Performance Impacts of Sessions?

If you have looked at very many of the Java "standard extensions" APIs, you
will note
that most of them define Java interfaces (and associated contracts
documented in the
spec and the Javadocs) that a particular implementation of that API must
conform to, but
they give the implementers a fair degree of freedom in *how* to conform to
requirements.  Thus, there is no general answer to the question "how does a
container implement the HttpSession interface."

However, it is worthwhile looking at the way Tomcat handles this -- most of
containers I'm familiar with do something similar.

Inside of Tomcat, the set of active sessions associated with a part of a web
are instances of the class org.apache.tomcat.session.StandardSession, which
has a few
small instance variables and a Hashtable to contain the user's session
beans.  For a
session with no session attributes, this is probably something on the order
of 50 bytes
of memory usage in the JVM's heap (why no precise answer?  well, it depends
on the
implementation of the JVM ....).  Tomcat also maintains a Hashtable of all
the active
sessions at any given point in time, inside a component called the

Individual sessions can store any number of session-scoped beans (JSP
terminology).  The
memory occupancy of those beans is totally dependent on the instance
variables in that
bean (there's only one memory copy of the bytecodes of any class in Java, so
how much
code there is has almost zero impact).  Note that you, as the developer,
have total
control over adding and *removing* these objects.  For example, as soon as
you are done
with a particular ActionForm bean in a Struts application, you should remove
it from the
session (in the Action class that received the final copy of the form) so
that it can be
garbage collected.  There's no reason to keep it around any longer than

Hashtables have the nice property that they support keyed access to even
large numbers
of objects with fairly linear response times.  Thus, it makes almost no
difference (from
a CPU time point of view) how many active sessions there are, or how many
session scope
beans you have in a particular sesison.

In general, you will run into performance issues on your database and
network long
before you run out of CPU time -- unless your app is particularly
CPU-intensive, so your
mileage may vary.

The bottom line -- if you don't need to maintain any state information
across requests
from the same user, you don't need sessions.  If you do need this, sessions
are a pretty
cheap way to meet that need.  What you need to do is plan the memory
appropriately (peak # of active sessions * peak memory for session scope
beans, if you
want to be conservative).

Craig McClanahan

View raw message