struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Struts Actions are Singletons?
Date Thu, 25 Apr 2002 14:49:01 GMT
The local variables mentioned below, are method scope. They have no baring on sessions.
For session held objects, yes, a cluster would need to replicate them (hence they need to
be Serializable).
However, the servlet spec mandates that all requests for a session, should go to the same
VM. Only in 
fail-over would the VM change.

-----Original Message-----
From: Adolfo Miguelez []
Sent: 25 April 2002 14:36
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?

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?

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.



>* Java's implementation of a stack per thread (which is where the
>   local variables go) makes it easy to avoid most threading problems
>   by simply using local variables for the per-request information.


>From: "Craig R. McClanahan" <>
>Reply-To: "Struts Users Mailing List" <>
>To: Struts Users Mailing List <>
>Subject: Re: Struts Actions are Singletons?
>Date: Wed, 24 Apr 2002 11:25:20 -0700 (PDT)
>On Wed, 24 Apr 2002 wrote:
> > Date: Wed, 24 Apr 2002 13:43:26 -0400
> > From:
> > Reply-To: Struts Users Mailing List <>
> > To: Struts Users Mailing List <>
> > Subject: Re: Struts Actions are Singletons?
> >
> >
> >
> >
> > Can someone explain why these are created as singletons in the first 
> >
>Are you speaking of Action instances?  If so, they are created as
>singletons for a number of reasons:
>* The threading behavior of Actions are exactly the same as those
>   of servlets and JSP pages, where it is quite common for several
>   requests to be present in your Action at the same time.
>* Java's implementation of a stack per thread (which is where the
>   local variables go) makes it easy to avoid most threading problems
>   by simply using local variables for the per-request information.
>* At the same time, it is quite common to have some of your data
>   shared across all requests that use a particular Action.  An example
>   would be a list of valid values for a particular form bean property --
>   you might well choose to read that information into a shared variable
>   at the beginning of your application, instead of going to the
>   database on every request.  An instance variable inside the action
>   (or perhaps a servlet context attribute if you need the list as part
>   of your UI also) makes a perfectly reasonable place to store these.
>Moving instance variables into the session, by the way, reduces (but does
>not eliminate) multiple thread concerns.  You still need to be aware of
>multiple requests accessing the same session at the same time.  "How is
>that possible?", you might ask -- consider:
>* User submits a form to a long running transaction, gets
>   impatient, presses STOP, and goes somewhere else in your
>   app (and therefore in the same session) before the first
>   request has completed.
>* You are using frames -- most browsers will submit multiple
>   simultaneous requests that will typically be accessing the
>   same session.
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

             <TITLE>Adolfo's signature</TITLE>
             <center><b><em>Adolfo Rodriguez Miguelez</em><b></center>


Join the world's largest e-mail service with MSN Hotmail.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

Visit our website at

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message