On Mon, 13 May 2002, Steven D. Monday wrote:
> Date: Mon, 13 May 2002 08:52:38 -0500
> From: Steven D. Monday <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> 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.
In most large scale application environments, your business logic layer is
very likely doing this kind of thing (allocating instances from a pool)
already, whether we do it or not with Actions. Session EJBs, for example,
work exactly this way. Doing it in the Actions, in that sort of an
environment, doesn't buy you any improvement by avoiding the need to
allocate instances in the back end.
The crucial difference, though, is that with the EJBs this extra work can
happen on your back end database server, instead of your front end web
container. You can scale the front end and back end independently, based
on where the bottlenecks are in your application.
This is not possible if you've tied everything together in the front end.
> 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.
>
Martin's quote doesn't really cover the entire issue -- you still have to
deal with multiple threads even with per-request Action allocations. Any
thinking that you don't is an illusion. Quite aside from the performance
and scalability questions, I'd rather make the need to program in a
thread-safe manner absolutely explicit in Struts, because forcing people
to think about it leads to programs with fewer bugs.
> Again, not saying maintaining a single instance of actions is not good or
> perhaps the best approach, just looking to understand.
>
> Thanks
> Steve
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
