struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Struts Actions are Singletons?
Date Thu, 25 Apr 2002 15:33:35 GMT


On Thu, 25 Apr 2002, Adolfo Miguelez wrote:

> Date: Thu, 25 Apr 2002 13:36:23 +0000
> From: Adolfo Miguelez <pelly69@hotmail.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Re: Struts Actions are Singletons?
>
> Pertainig to the paragraf below extracted from the Craig response, I wonder
> a question. What happens in clustered environments, where the VM can be swap
> in a per request basis?
>

In the servlet specification, support for this is described as a
"distributed container", and you include the <distributable/> attribute in
your web.xml file to indicate that you've programmed to a couple of extra
standards to work correctly in such an environment.

> State is not lost if it is maintained in session since, as far as I know,
> server is able to serialize the session and feed next server with session
> state, BUT by using stack objects, state could be lost, is not it?
>

State can be maintained in the session, even in the face of load balancing
and failover, as long as you make all of your sesson attribute classes
implement Serializable (and that restriction applies to any instance
variables inside your session attributes as well).  Note that the
container has a useful restriction -- all requests for a particular
session, at a particular time, must be answered by one instance.  In other
words, migration can only happen in between requests.  From the
application perspective, that lets you deal with thread safety issues here
exactly like you do in a single-server environment.  For example, you
don't ever have to figure out how to synchornize a session attribute
across multiple JVMs.

For stuff on the stack, remember that it only has a maximum lifetime equal
to the length of an individual request itself (just like request
attributes), even in the non-load-balanced case.  That is why, for
example, you must include input fields for *all* your form bean properties
when you are using request scope form beans, so that the entire state can
be restored. Therefore, you've got no problems unless the server tries to
migrate your request in the middle of that request.  And I don't know of
any servers that actually try that.

> I would appreciate opinions, Craig opinion especially welcome, since in my
> understanding implementation of stacks per thread in such a case is quite
> tricky since servers can be balanced.
>

If you want to rely on more than my opinion :-), you would find some very
useful information in the Servlet Specification (version 2.3) and the J2EE
Platform Specification (version 1.3).  These describe the programming
environments that portable applications can expect in a J2EE container -
even one that supports advanced features like load balancing and failover.
Containers can provide additional capabilities, and it's certainly
possible to write applications dependent on those capabilities - but it's
our responsibility as developers to understand what is portable and what
is not.

> Regards,
>
> Adolfo.
>

Craig


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message