You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Girish Baxi <gb...@digitalconcepts.com> on 2001/04/10 18:41:01 UTC

Session scope

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



Re: Session scope

Posted by "Craig R. McClanahan" <cr...@apache.org>.

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