I have another question in my mind that relates to the scalability
and performance:
What are the general guide lines to consider when deciding to
put my form beans into request scope vs. session scope?
My first cut thinking is as follows:
1) When session object is not available, request scope is
the only option (simple);
2) When users have multiple browser windows that might
access the same form bean, for thread safe purpose, it is
better to put it into request scope (rare use cases)
3) When developing wizard like application, it looks to me
session scoped form beans should be the primary option.
(Is there someone out there using request scoped form
beans for a multi-page application? I would like to
know the reasons behind)
4) Conditions beyond 1 - 3. I feel hard to make decisions here.
If I put form beans into request scope, then every request,
Struts will create form beans and destroy them too.
It mean slower performance, but good scalability.
If I put form bean into session scope, I avoid the instance
creation on every request, but I would end up large
session scoped objects that impact session migration.
I also heard that there might be some limit on the size
of the session scoped objects, it that true in general?
I could miss some other conditions to consider, and would
like to hear any insights, project experiences, etc. regard to
this question.
Jing
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, May 13, 2002 11:31 AM
Subject: RE: Scalability question
>
>
> 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
