Re[2]: Dynamic creation of Actions's with 'forName'

[Oleg V Alexeev <go...@penza.net>]

Hello Craig,

Interesting question and clear answer... 8)

What do you think about such caching for Class? With this approach we
call forName() method only once - no other overhead.

public class EntityMapping {

       protected Class cach = null;

       protected String type = null;

       public String getType() {
              return type;
       }

       public void setType( String type ) {
              this.type = type;
       }

       public Class getStub() throws ClassNotFoundException {
              if( cach!=null )
                  cach = Class.forName( type );
              return cach;
       }

       public Entity getEntity() throws ClassNotFoundException {
              return getStub().newInstance();
       }
       
}


Wednesday, June 20, 2001, 12:31:03 AM, you wrote:



CRM> On Tue, 19 Jun 2001 andrew.bate@sts.co.uk wrote:

>> Hi,
>> 
>> Is anyone using the STRUTS framework in a production environment yet?
>> 
>> We're currently developing a MVC based webapp and are looking at 
>> potentially taking a step backwards and basing it around STRUTS.  One area 
>> of concern is the dynamic creation of the Action objects using 'forName'.  
>> What sort of performance hit does this give?
>> 
>> Advice from our Tech Architect at the moment seems to be to look at STRUTS 
>> but write our own version and he's not too keen on 'forName' processing.  
>> Is this an unfounded concern?
>> 

CRM> There are several considerations to think about in trying to address this
CRM> concern:

CRM> * How often does it happen?  In Struts, objects are created
CRM>   dynamically only under the following circumstances:
CRM>   - The first time a particular Action class is accessed (so it's not
CRM>     really relevant to discussions about performance impacts).
CRM>   - When you are a using form bean, AND the form bean does not already
CRM>     exist in appropriate scope.  If you adopt a pure MVC approach (and
CRM>     flow all your requests through the controller), you can easily
CRM>     arrange to create form bean instances from a recyclable pool if
CRM>     you want to.

CRM> * Does it matter when it does happen?  One of the most striking
CRM>   differences between modern HotSpot-based JVMs and earlier generations
CRM>   is that the cost of object creation (and the subsequent garbage
CRM>   collection) has been dramatically reduced.  I have had people who are
CRM>   pretty sharp tell me that object pooling can easily cost you more
CRM>   performance than it saves by avoiding object creations, in many
CRM>   circumstances.

CRM> * Is it worth the cost?  The point of many features of Struts (or any
CRM>   other application framework) is to accelerate development, and to
CRM>   reduce ongoing maintenance costs by making your architecture naturally
CRM>   easier to maintain.  Is this worth throwing a little extra hardware
CRM>   at the server to deal with any perceived "overhead" of object creation?
CRM>   For many people, the answer is "yes, absolutely".  And projections for
CRM>   the future cost of a developer's time, as compared to the cost of
CRM>   "x" MIPs worth of CPU time, is going to make this even more attractive.

CRM> As you can see, there's no cut-and-dried answer.  Dynamic object creation
CRM> has a cost (which can be mitigated in your application design).  So does
CRM> introspection to do the BeanUtils.populate() trick of copying request
CRM> parameters into bean properties (which vastly reduces the work needed to
CRM> create and maintain form bean classes).  Like everything, it's a balance
CRM> of cost versus benefit.  And the benefits can be quite dramatic.


>> Regards,
>> 

CRM> Craig McClanahan




-- 
Best regards,
 Oleg                            mailto:gonza@penza.net

Re: Re[4]: Dynamic creation of Actions's with 'forName'

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 21 Jun 2001, Oleg V Alexeev wrote:

> Hello Craig,
> 
> Wednesday, June 20, 2001, 8:52:18 PM, you wrote:
> 
> CRM> On Wed, 20 Jun 2001, Oleg V Alexeev wrote:
> 
> >> Hello Craig,
> >> 
> >> Interesting question and clear answer... 8)
> >> 
> 
> CRM> Yah, I really enjoy the interesting ones :-).
> 
> >> What do you think about such caching for Class? With this approach we
> >> call forName() method only once - no other overhead.
> >> 
> 
> CRM> Class loaders do this kind of caching already, so I guess I don't see all
> CRM> that much benefit.
> 
> CRM> For Struts in particular, if you're concerned about repeated
> CRM> Class.forName() calls, a better strategy is avoidance -- arrange your
> CRM> application so that the form beans are created for you ahead of
> CRM> time.  Then Struts will never have to call it.
> 
> Sorry, but I have not idea how to do so. Explain please, how can I
> "arrange your application so that the form beans are created for you
> ahead of time"? Is it step in struts-config or no?
> 

I guess that comment was a little bit terse ...

Basically, I like the design pattern where there are no links from one
page directly to another page -- instead, you always go through an
Action.  In particular, this action can create the form bean and install
it into the appropriate scope (either request or session), and then
forward to the page.  The action could choose to recycle such beans from a
pool, if it wanted to.

An instance of this pattern is in the Struts example application.  When
you select the option to modify existing registration information, the
link goes to path "/editRegistration.do", which creates the appropriate
form bean and then forwards to "/registration.jsp".  Now, the <html:form>
tag on that page will see that the bean already exists, so it does not
need to be instantiated.

The other place Struts creates form beans dynamically is in the
controller, when processing the incoming request.  Again, this only
happens if the form bean does not alredy exist in appropriate scope.  For
example, if you use session scope then the existing bean will be reused,
so a particular bean will only be created once (instead of once per
request).

> CRM> Or, throw you can just throw hardware at it and take advantage of Moore's
> CRM> Law ... :-)
> 
> -- 
> Best regards,
>  Oleg                            mailto:gonza@penza.net
> 
> 

Craig

Re[4]: Dynamic creation of Actions's with 'forName'

[Oleg V Alexeev <go...@penza.net>]

Hello Craig,

Wednesday, June 20, 2001, 8:52:18 PM, you wrote:

CRM> On Wed, 20 Jun 2001, Oleg V Alexeev wrote:

>> Hello Craig,
>> 
>> Interesting question and clear answer... 8)
>> 

CRM> Yah, I really enjoy the interesting ones :-).

>> What do you think about such caching for Class? With this approach we
>> call forName() method only once - no other overhead.
>> 

CRM> Class loaders do this kind of caching already, so I guess I don't see all
CRM> that much benefit.

CRM> For Struts in particular, if you're concerned about repeated
CRM> Class.forName() calls, a better strategy is avoidance -- arrange your
CRM> application so that the form beans are created for you ahead of
CRM> time.  Then Struts will never have to call it.

Sorry, but I have not idea how to do so. Explain please, how can I
"arrange your application so that the form beans are created for you ahead of
time"? Is it step in struts-config or no?

CRM> Or, throw you can just throw hardware at it and take advantage of Moore's
CRM> Law ... :-)

-- 
Best regards,
 Oleg                            mailto:gonza@penza.net

Re: Re[2]: Dynamic creation of Actions's with 'forName'

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 20 Jun 2001, Oleg V Alexeev wrote:

> Hello Craig,
> 
> Interesting question and clear answer... 8)
> 

Yah, I really enjoy the interesting ones :-).

> What do you think about such caching for Class? With this approach we
> call forName() method only once - no other overhead.
> 

Class loaders do this kind of caching already, so I guess I don't see all
that much benefit.

For Struts in particular, if you're concerned about repeated
Class.forName() calls, a better strategy is avoidance -- arrange your
application so that the form beans are created for you ahead of
time.  Then Struts will never have to call it.

Or, throw you can just throw hardware at it and take advantage of Moore's
Law ... :-)

Craig