ActionForm scope suggestion

[David Chisholm <Da...@i2.com>]

I have a suggestion for the ActionForm: Do not limit the scope of an
ActionForm to session.  Allow it to be configurable, so that the application
can choose between at least session and request level scope for an
ActionForm.  Here's why:

* Since ActionForms have session scope, it's not possible to allow the
client to access the same form in two or more different windows because the
last form to update the ActionForm instance will override the previous
form's inputs and likely corrupt the other window's state.

* There's also the issue of reclaiming resources allocated for ActionForms.
If you have 1000 simultaneous users, 100 ActionForms, and an average of 10
String fields per ActionForm, then in the worst case scenario you would have
1,100,000 objects allocated just for ActionForms (number of total String
objects in ActionForms + number of total ActionForm objects).  A session's
ActionForm resources will not be reclaimed until the session is invalidated
and garbage collected.  So a session can tie up a lot of memory in
ActionForms even though it may only reuse a fraction of its ActionForm
objects regularly.

The counter argument to this is the cost of allocating/freeing new objects
per request for a request-scope ActionForm.  This cost can be mitigated
however using an object pool to cache and reuse ActionForm objects, and in
general, would be a less resource hungry solution.

* Finally, there's the issue of load balancing and fail-over.  No matter
whether sessions are load-balanced/failed-over using disk storage or
mirrored with in-memory caches, the larger the session, then the longer it
will take to copy the session data amongst the clustered servers.  Every
time a session is changed, it has to be replicated across the cluster.
Conceivably this could occur on every request if you have an ActionForm for
every page.  (Btw, when the ActionForm changes, is the session object
notified?  Also, I don't think ActionForm implements Serializable, so it
can't be replicated across a cluster anyway.)

Adding scope as an ActionForm attribute provides a finer grain of control
for the application to address the above issues on a per form basis.  A
global default scope, similar to the global default forward/redirect
attribute, would be very useful as well.  An application could set the
default ActionForm scope to 'session' and override the scope for specific
forms.

Finally, the 'session' and 'request' scope levels are clearly useful, but I
don't know about the usefulness of the other scope levels.

Would this suggestion be useful to anyone else?

David

Re: ActionForm scope suggestion

["Craig R. McClanahan" <Cr...@eng.sun.com>]

I just added the capability to use request scope form beans (see a
message
summarizing all the new features from this weekend's hacking
separately), but I
wanted to thank David for this suggestion and throw in a few comments on
his
points.

David Chisholm wrote:

> I have a suggestion for the ActionForm: Do not limit the scope of an
> ActionForm to session.  Allow it to be configurable, so that the application
> can choose between at least session and request level scope for an
> ActionForm.  Here's why:
>
> * Since ActionForms have session scope, it's not possible to allow the
> client to access the same form in two or more different windows because the
> last form to update the ActionForm instance will override the previous
> form's inputs and likely corrupt the other window's state.
>
> * There's also the issue of reclaiming resources allocated for ActionForms.
> If you have 1000 simultaneous users, 100 ActionForms, and an average of 10
> String fields per ActionForm, then in the worst case scenario you would have
> 1,100,000 objects allocated just for ActionForms (number of total String
> objects in ActionForms + number of total ActionForm objects).  A session's
> ActionForm resources will not be reclaimed until the session is invalidated
> and garbage collected.  So a session can tie up a lot of memory in
> ActionForms even though it may only reuse a fraction of its ActionForm
> objects regularly.
>

The form beans will only accumulate (in the user's session) if you
neglect to
remove them.  My habit is to have my Action classes do a
"session.removeAttribute()" call when I know that I am done with a
particular
form.

Note that this does not invalidate the other reason that David cites for
wanting
request scope beans (primarily the idea that a user might be navigating
in
multiple windows simultaneously).

>
> The counter argument to this is the cost of allocating/freeing new objects
> per request for a request-scope ActionForm.  This cost can be mitigated
> however using an object pool to cache and reuse ActionForm objects, and in
> general, would be a less resource hungry solution.

I did not implement a cache of form bean instances at this point.  Doing
so
would require, among other things, that we add a reset() method on every
form
bean instance to set it's values back to the bean's defaults. 
Otherwise, a
newly created bean and a bean retrieved from the recycle bin would not
have
identical property values.

If we find that this is a performance issue, we can add recycling later.

>
> * Finally, there's the issue of load balancing and fail-over.  No matter
> whether sessions are load-balanced/failed-over using disk storage or
> mirrored with in-memory caches, the larger the session, then the longer it
> will take to copy the session data amongst the clustered servers.  Every
> time a session is changed, it has to be replicated across the cluster.
> Conceivably this could occur on every request if you have an ActionForm for
> every page.  (Btw, when the ActionForm changes, is the session object
> notified?  Also, I don't think ActionForm implements Serializable, so it
> can't be replicated across a cluster anyway.)
>
> Adding scope as an ActionForm attribute provides a finer grain of control
> for the application to address the above issues on a per form basis.  A
> global default scope, similar to the global default forward/redirect
> attribute, would be very useful as well.  An application could set the
> default ActionForm scope to 'session' and override the scope for specific
> forms.
>
> Finally, the 'session' and 'request' scope levels are clearly useful, but I
> don't know about the usefulness of the other scope levels.
>
> Would this suggestion be useful to anyone else?
>
> David

David, please try out the new support and let me know what you think! 
Sorry it
took so long, but JavaOne (plus its follow-up) as occupied a lot of
time.  I
finally got some time this weekend to add functionality to Struts.

Craig

Re: Can't figure extending ActionMapping

["Craig R. McClanahan" <Cr...@eng.sun.com>]

joaquim wrote:

> Sorry if this is dumb...
>

It's not dumb ... and it's not documented very well.

>
> I don't understand the ideia of extending ActionMapping in the example
> application and in the docs. My doubts are the following:
>
> 1) Can't see how my app informs struts that I have implemented ActionMapping
> or extended ActionMappingBase.
>

You tell Struts that you have done this by setting a servlet initialization
parameter for the ActionServlet instance named "mapping".  The value you enter
here is the fully qualified Java class name for your extended class.

(The same principle applies to extending ActionForward if you need to -- simply
set the "forward" initialization parameter to the fully qualified name of that
class.)

>
> 2) In the example ApplicationMapping extends ActionMappingBase by adding two
> properties: "success" and "failure".  But the functionality of this is
> obscure to me, because I think that the <forward name="success" ...> and
> <forward name="failure"...> elements in action.xml do exactly what these
> properties were supposed to do. Or is it necessary to have the name in
> forward elements as properties of an ActionMapping implementation?
>

You are quite perceptive here.

The original version of the example application used "success" and "failure"
properties to store the URIs of the pages to which an action should forward
under logical conditions named "success" and "failure".  While this approach
works, it is somewhat restrictive, because you have these properties (and only
these properties) on every single mapping entry.

The <forward> mechanism was added to generalize the idea that you might want to
have any number of named "destinations" to which control should be forwarded,
and that you might want a choice between forwarding and redirecting.  Thus, the
need to extend ActionMapping is substantially reduced, although it is still
available in case you want to pass other configuration parameters to your Action
implementation classes that can be defined at configuration time.

In fact, the example application no longer requires the extended
ApplicationMappingBase class, because everything it needed was covered by the
<forward> enhancements.

>
> 3) If I do write my own ActionMapping implementation how exactly would I
> initialize my own properties in action.xml?
>

Let's assume you created a MyActionMapping class that added properties "foo" and
"bar".  In Java programming terms, that means you added four methods to your
class:
    public String getFoo()
    public void setFoo(String foo)
    public String getBar()
    public void setBar(String bar)

to initialize these properties in your <action> entry, simply add attributes
named "foo" and "bar" like this:

    <action path="/mypath" ... foo="new foo value" bar="new bar value"/>

and Struts will match up the attribute names with the corresponding "set"
methods (setFoo() and setBar()), by following the usual JavaBeans naming style
-- start with "set" and capitalize the first letter of the attribute.

>
> --
>  Joaquim Ramos de Carvalho
> Instituto de Historia e Teoria das Ideias / Centro de Informatica e Sistemas
> da Universidade de Coimbra. 3049 COIMBRA CODEX PORTUGAL
> joaquim@dei.uc.pt

Craig McClanahan

Can't figure extending ActionMapping

[joaquim <jo...@dei.uc.pt>]

Sorry if this is dumb...

I don't understand the ideia of extending ActionMapping in the example
application and in the docs. My doubts are the following:

1) Can't see how my app informs struts that I have implemented ActionMapping
or extended ActionMappingBase.

2) In the example ApplicationMapping extends ActionMappingBase by adding two
properties: "success" and "failure".  But the functionality of this is
obscure to me, because I think that the <forward name="success" ...> and
<forward name="failure"...> elements in action.xml do exactly what these
properties were supposed to do. Or is it necessary to have the name in
forward elements as properties of an ActionMapping implementation?

3) If I do write my own ActionMapping implementation how exactly would I
initialize my own properties in action.xml?





-- 
 Joaquim Ramos de Carvalho
Instituto de Historia e Teoria das Ideias / Centro de Informatica e Sistemas
da Universidade de Coimbra. 3049 COIMBRA CODEX PORTUGAL
joaquim@dei.uc.pt