On Mon, 13 May 2002, Steven D. Monday wrote:
> Date: Mon, 13 May 2002 07:57:29 -0500
> From: Steven D. Monday <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: Scalability question
>
>
> In the paragraph below Craig mentioned that the "same one (action instance)
> is reused continuously". I'm curious as to the rationale behind
> maintaining a single instance of each action class, especially given that
> it does introduce the requirement (unfortunately not always understood by
> developers) that actions be written in a reentrant fashion. I'm assuming
> that it was perhaps a performance optimization?
Yes -- although it's even more important for scalability (how many
simultaneous requests can I serve) than performance (how fast can I serve
this particular request).
Creating and destroying Action instances, or pooling them in between uses,
takes processor time (and more memory) to manage -- and it doesn't buy you
*anything* except the ability to write Action classes in a thread-unsafe
manner. And even that doesn't protect you from all possible threading
problems -- for the same reasons that SingleThreadModel doesn't help.
You *still* need to deal with the fact that a session can be accessed on
multiple threads simultaneously.
> However, it seems that if
> an action class invokes any kind of serious business process that the
> time/resources expended creating (even reflectively) and destroying an
> action instance would pale compared to time/resources expended by the
> business object model. Just curious.
>
Why pay for something that doesn't help you, especially when it is
straightforward to write stateless Action classes? In fact, business
logic should be delegated to EJBs or DAOs or things like that anyway --
the primary purpose for an Action class is to just pull the data out of
the request (and form bean), and set up the corresponding business method
calls.
> Thanks
> Steve
>
Craig
> >Action instances have exactly the same thread processing characteristics
> >as non-STM servlets - the single instance is utilized by multiple requests
> >(on different threads) simultaneously. This has two important
> >implications:
>
> >* You (and Struts) don't have to worry about pooling Action instances -
> > the same one is reused continuously, with no locking or allocation
> > overhead.
>
> >* You must program your Action instances in a thread-safe manner.
> > The most important rule is to not store any per-request state
> > information in instance variables in the Action class.
>
>
>
> "Craig R.
> McClanahan"
> <craigmcc@apa
> che.org>
>
> 05/10/2002 To: Struts Developers List
><[EMAIL PROTECTED]>
> 06:23 PM cc:
> Please
> respond to
> "Struts
> Developers Subject: RE: Scalability question
> List"
>
>
>
>
>
> Caterpillar: Confidential Green Retain Until: 06/09/2002
> Retention Category: G90 -
> Information and Reports
>
>
>
>
>
>
> On Fri, 10 May 2002, David Cherryhomes wrote:
>
> > Date: Fri, 10 May 2002 15:14:34 -0700 (PDT)
> > From: David Cherryhomes <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: RE: Scalability question
> >
> > I'm sorry, maybe I was unclear. I am not challenging the
> > usefulness of Struts, I am well aware of the vast amount of
> > functionality that the framework encompasses. I am currently
> > using Struts as a core part of the MVC approach in my enterprise
> > application. My question is about the scalability of Struts
> > Action classes.
> >
> > It is my understanding that a Servlet engine will create new
> > instances/threads of a Servlet as needed (similar to stateless
> > session beans), and hence is very scalable for multiple
> > concurrent requests.
>
> This is true only if your servlet implements the SingleThreadModel (STM)
> interface. If it doesn't, a single instance of your servlet is allocated
> and is shared by all concurrent requests. The Struts controller servlet
> is an example of this (it is not an STM servlet) -- there is one and only
> one instance of this servlet for your webapp.
>
> > My understanding is that an Action class,
> > on the other hand, is stored as an instance variable.
>
> The set of Action instances that have been created are stored in a servlet
> instance variable, but they are reused on multiple requests for the same
> action. In fact, Struts makes a similar guarantee about Action instances
> to what the servlet container promises about non-STM servlets -- there
> will be at most one occurrence of any given Action implementation class.
>
> > The
> > question is this: if I have a class that performs a massive
> > amount of business processes (inclusive of attaching to multiple
> > EJB's), will the multiple concurrent requests end up queued in a
> > wait status until each one is finished processing, or is there a
> > multiple instance/thread approach to Action classes (similar to
> > a Servlet engine with Servlets)?
> >
>
> Action instances have exactly the same thread processing characteristics
> as non-STM servlets - the single instance is utilized by multiple requests
> (on different threads) simultaneously. This has two important
> implications:
>
> * You (and Struts) don't have to worry about pooling Action instances -
> the same one is reused continuously, with no locking or allocation
> overhead.
>
> * You must program your Action instances in a thread-safe manner.
> The most important rule is to not store any per-request state
> information in instance variables in the Action class.
>
> > The enterprise application I'm working on isn't for some
> > website, but a truly web-deployed enterprise app which must
> > scale to thousands of concurrent users with millions of records
> > in the DB. Thus, performance is a HUGE concern (e.g., a wait of
> > 500 miliseconds is about the max permitted).
>
> As long as the servlet container you're running on can support the number
> of simultaneous requests you need, you're going to find that Struts is
> basically irrelevant to scalability on the business logic side of things.
> You will definitely have to configure your EJB server to support adequate
> pools of bean instances, because they do act like STM servlets.
>
> In the presentation layer, using Struts (or more precisely, using the
> Struts tag libraries) can have a performance and response time impact,
> depending on the quality of the code generated by the JSP page compiler in
> your servlet container. As long as you don't exceed the simultaneous
> response capabilities of your container, this is primarily an issue of CPU
> time in the web tier servers.
>
> >
> > Thanks
>
> Craig
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
> >
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
> >
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
