Regarding Action Instances:
They are stored in HashMap (FastHashMap actually) that is kept by the
primary ActionServlet. This ActionServlet is the same one as is defined as
a startup servlet in the web.xml of each web application running struts in
a particular servlet container instance.
While some of this may depend on your particular servlet container, I'd
venture to guess that its likely that information isn't replicated between
clustered container instances unless the information is specifically put on
the Session (or potentially, the Application) context. That's not the case
with the Action instances - they are stored in the memory space used by the
servlet itself.
So it looks like this information is likely not replicated among clustered
instances.
But really what does it matter? It's unlikely that you'll be storing
session information in an Action instance that is shared by multiple
sessions anyway.
In other words, since you're not going to store per-session information in
the Action instance, replication of session information in a cluster is
irrelevant.
That being said, it may be possible that APPLICATION-LEVEL configuration
information may get out of whack if it is stored in an Action instance.
Each container would maintain this information independantly, so this may
be something to look out for.
FWIW -
Kevin
"Adolfo Miguelez" <[EMAIL PROTECTED]> on 04/25/2002 09:36:23 AM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
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.
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" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: Re: Struts Actions are Singletons?
>Date: Wed, 24 Apr 2002 11:25:20 -0700 (PDT)
>
>
>
>On Wed, 24 Apr 2002 [EMAIL PROTECTED] wrote:
>
> > Date: Wed, 24 Apr 2002 13:43:26 -0400
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > 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:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
<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:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
