Stateful applications

[David van Coevorden <st...@yahoo.com>]

Hi ,

As a newbie I have a question regarding
stateful-/stateless-ness. I am aware that it is
sometimes pointed out that stateful web applications
do not scale very well. 

* First: can anyone give me some arguments pro/con or
refer me to a good resource?
* Second: does struts typically keep state (I think so
because it keeps the user session) and if so, is it
subject to scalability problems? Is struts's
statefulness connected to statefulness of an
application consisting of EJB's running "behind"
struts, or can the two be viewed separately?

I would be very grateful for any hints or arguments or
links to other useful info.
Thanks!

David


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: Stateful applications

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 7 Aug 2001, David van Coevorden wrote:

> Hi ,
> 
> As a newbie I have a question regarding
> stateful-/stateless-ness. I am aware that it is
> sometimes pointed out that stateful web applications
> do not scale very well. 
> 

That is a *slightly* simplistic view of the world, but has some validity
:-).

> * First: can anyone give me some arguments pro/con or
> refer me to a good resource?

I would certainly look to what the various app server providers say about
designing highly scalable applications that run on their platforms.  Be
aware that the optimum designs might differ slightly per platform,
depending on what particular areas that vendor has focused on.

> * Second: does struts typically keep state (I think so
> because it keeps the user session) and if so, is it
> subject to scalability problems?

The primary "state" information for Struts is the ActionForm bean that you
use to capture the request parameters on a form submit.  Struts gives you
the choice of either request scope or session scope.

Request scope should be used when you can -- the only time this is
problematic is when you have a transaction that requires more than one
interaction with the user.  The "state" that you care about here is the
input data from forms other than the current page.  Here, the choices
basically boil down to:

* Keep the state information in the user's session (but be sure you
  remove it when you're through with that particular transaction).

* Keep the state information in hidden variables on each page so that
  you can continue to use request scope.

* Store the state data externally in a database or EJB, and then keep
  track of a reference to that data (so it can be retrieved on the
  next request) in the user's session, or in a cookie.

> Is struts's
> statefulness connected to statefulness of an
> application consisting of EJB's running "behind"
> struts, or can the two be viewed separately?
> 

They can overlap if you want to.  For example, if you wanted to implement
the third Struts-state strategy above using the EJB layer, you could use
stateful session beans -- you grab one when the transaction starts, and
release it when the transaction ends.  From the Struts perspective you
only need to keep track of the reference to the stateful session bean
you've allocated -- this is small enough to store in the web layer session
without too much grief.

Conceptually, this is exactly the same as storing state in session scope
-- it is still occupying memory somewhere on the server.  However, using
an EJB this way lets you split up the work (your EJBs might be running on
a different server, or a farm of different servers, so that you can scale
the front end and the back end independently as needed).

> I would be very grateful for any hints or arguments or
> links to other useful info.
> Thanks!
> 

There are no really simple solutions that work all the time.  But
everything starts with an analysis of how many simultaneous users you plan
to support, how much state data each user will have for each possible
transaction, and how much memory you plan to install.

> David
> 

Craig