struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hal Deadman" <hal.dead...@Tallan.com>
Subject RE: Scalability question
Date Mon, 13 May 2002 14:19:02 GMT
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:MONDAY_STEVEN_D@cat.com]
> 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'" <struts-dev@jakarta.apache.org>
>                     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:MONDAY_STEVEN_D@cat.com]
> > 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
> > <struts-dev@jakarta.apache.org>
> >                     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 <dcherryhomes@yahoo.com>
> > > Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> > > To: Struts Developers List <struts-dev@jakarta.apache.org>
> > > 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:struts-dev-unsubscribe@jakarta.apache.org
> > >
> > For additional commands, e-mail:
> > <mailto:struts-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-dev-help@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-dev-unsubscribe@jakarta.apache.org
> >
> For additional commands, e-mail:
> <mailto:struts-dev-help@jakarta.apache.org
> >
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message