struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adolfo Miguelez" <pell...@hotmail.com>
Subject Re: Struts Actions are Singletons?
Date Thu, 25 Apr 2002 13:36:23 GMT
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.

Regards,

Adolfo.


>* 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" <craigmcc@apache.org>
>Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>To: Struts Users Mailing List <struts-user@jakarta.apache.org>
>Subject: Re: Struts Actions are Singletons?
>Date: Wed, 24 Apr 2002 11:25:20 -0700 (PDT)
>
>
>
>On Wed, 24 Apr 2002 Kevin.Bedell@sunlife.com wrote:
>
> > Date: Wed, 24 Apr 2002 13:43:26 -0400
> > From: Kevin.Bedell@sunlife.com
> > Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > Subject: Re: Struts Actions are Singletons?
> >
> >
> >
> >
> > Can someone explain why these are created as singletons in the first 
>place?
> >
>
>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.
>
>Craig
>
>
>--
>To unsubscribe, e-mail:   
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:struts-user-help@jakarta.apache.org>
>




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

      </BODY>
      </HTML>





_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


--
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