Obviously, design decisions have been made on the session context.
Is anyone running (or considering running) Struts in a truly distributed
server infrastructure?
Does Craig's suggestion of Serializable session beans stand up under volume?
Just looking for some pointers.
Jim
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 11:03 PM
To: Struts-User@Jakarta. Apache. Org (E-mail)
Subject: Re: Session scope
On Tue, 10 Apr 2001, Girish Baxi wrote:
> I am a new strut user .... as far as i know , isnt it a bad idea to store
> data in the session scope simply becoz its not scalable for a multiple web
> server scenario ...
> is there any work around to using session scope in case of form beans that
> span more than one html page ???
>
> any guidance is appreciated,
> thanx
>
>
>
Let's understand what is really happening in order to understand what the
potential impacts are:
* An HttpSession, as implemented by your servlet container, typically
uses something like a Hashtable or a HashMap to store session
attributes.
* When you create a bean instance, the bytecodes that make up the
executable methods of your bean are shared across all instances -- the
only thing that takes memory is the bean properties themselves.
* Let's assume that your bean uses about 1000 bytes for the properties
that are unique to that bean, and you want to save a bean in each
user's session because it represents information you need over more
than one request.
* If you have 10,000 simultaneous users, that means you need roughly
ten megabytes (10,000 * 1000) of memory to store these objects. Whether
that is a problem or not depends on how much free memory you have.
* Some application servers support load balancing and distribution
facilities, so that they can handle more users than can be supported
by a single server. Essentially, they are running a copy of your
web application on each server. In order to facilitate migrating
your session from one server to another, they may require you to make
all of your session beans Serializable.
The bottom line is that, like everything else, use of session beans
involves tradeoffs. If you are running amazon.com or Yahoo, you care a
lot about memory occupancy. If you're writing an Intranet app for 50
users in your department, it's probably not a big deal unless you have
very large data objects to be stored. You should analyze your expected
simultaneous user counts, and the typical amount of memory that their
session attributes require. Compare that to the amount of available
memory on your server. The results of this comparison will tell you how
much (or little) you need to worry about the amount of space session
variables require.
Craig McClanahan