I do make my Business delegates instance variables of my Action classes because they are thread-safe (and the controller does have to depend on the model). They are light-weight objects but it's nice that I only have to create them once, which I can do in the constructor because there is only one instance of each Action.
My business delegates use a singleton ServiceLocator class that caches the InitialContext and EJB home interfaces that are looked up (thank-you EJBX). I rely on the container to make creating session bean remote interfaces efficient. If someone is doing Struts, they should already be familiar with the way Servlets&JSPs have to be made thread-safe so I don't think it should be a problem for novice programmers. I am not trying to come across as an authority, I am just speaking from my experience and I like the fact Action classes are only created once. Hal > -----Original Message----- > From: Steven D. Monday [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 13, 2002 9:53 AM > To: Struts Developers List > Subject: RE: Scalability question > > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
