Hal,
Thanks for the reply. I don't think I was attempting to make a point as much as learn some of the rationale behind the choice of a single action instance as opposed to creating an action instance perhaps upon every request for example. A couple follow up questions. > Action classes aren't supposed to have any kind of serious business process. I didn't mean to imply that an action class itself would implement serious business logic itself. However, unless I'm misunderstanding the role of an action class I would assume that it would perhaps instantiate a business object and ask it to perform some service. My point was that in the act of performing a service the business object would likely exhaust more cpu cycles/memory than would be expending creating an action class instance and garbage collecting it. What motivated me to ask this question was the following verbage I found on Martin Fowler's site: http://www.martinfowler.com/isa/frontController.html, regarding front controller command classes and thread-safety: "Since you create new command object with each request, you don't have to worry about making the command classes thread safe. This can avoid the headaches of multi-threaded programming. You do have to make sure that you don't share any other objects, such as the model objects." > Also, if you are creating an Action for every request, there isn't much > point in having instance variables that might cause serialization issues, > so why have more than one instance? In principle I agree. However, again in reality it many times is the case that developers don't consider thread safety issues as closely as they should. This reality coupled with Martin's comments above made me curious as to what maintaining a single instance of commands buys you. Again, not saying maintaining a single instance of actions is not good or perhaps the best approach, just looking to understand. Thanks Steve "Hal Deadman" <hal.deadman@T allan.com> 05/13/2002 08:22 AM To: "'Struts Developers List'" <[EMAIL PROTECTED]> Please respond cc: to "Struts Developers List" Subject: RE: Scalability question Caterpillar: Confidential Green Retain Until: 06/12/2002 Retention Category: G90 - Information and Reports Action clases aren't supposed to have any kind of serious business process. You should keep your business objects "Struts-free". That's why you don't pass ActionForms directly to EJBs or business components. Struts needs to stop at the view-controller because the model should not depend on the view. Also, if you are creating an Action for every request, there isn't much point in having instance variables that might cause serialization issues, so why have more than one instance? If you are saying that there should be one Action instance per session then I would argue that you should manage your use of the session seperately, it's not in the Action classes' domain. Hal > -----Original Message----- > From: Steven D. Monday [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 13, 2002 8:57 AM > To: Struts Developers List > 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? 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. > > Thanks > Steve > > >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] > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
