You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2006/01/18 17:23:03 UTC

Re: Action Framework: simultaneous requests on the same path, in the same session.

Hi Arnaud,

On Wed, January 18, 2006 10:56 am, Arnaud Diederen said:
>
> Hello,
>
> [I've searched the web and the archives, but couldn't find anything
> useful (I'm not sure the terms of my queries were appropriate/efficient)]
>
> My problem is this (I'm using struts 1.2.7):
>
> When someone uses my webapp, some javascript sometimes triggers twice
> the same action in a very short amount of time (I mean: two POST
> requests are issued that call the same action's execute()) _with
> different parameters_.

I would start by asking if this is an app-level problem... is this quick
or double-submit, however you look at it, something you expect and have to
allow for?  I am having trouble imagining a scenario where you would want
to allow this, but that doesn't mean it isn't legitimate.  Is it? :)

> I noticed that the action sometimes receives the same set of parameters
> twice. Further investigation confirms that the form is populated for the
> first time, then for the second time and that, only then, the execute()
> method is called twice. That is due to thread concurrency, I suppose.

When the Action gets the same set of parameters, can you tell if its the
first set or the second set?  I would tend to expect to only ever see the
second set.

But then again, this would only occur for session-scoped forms as
request-scoped forms would be created anew with each request.

> In the RequestProcessor, I noticed there's no synchronization on the
> form, in the process() method, that ensures that the form is populated
> and then the action executed with the set of parameters it was supposed
> to receive.
> I did a little modification in RequestProcessor (actually, I extended
> it) and came up with:

Without actually confirming any of this, what you describe seems logical. 
With no concurrency control on the form object, the second request could
theoretically occur at just the right time so as to overwrite the values
in the form that the first request put there and only then is execute()
called (that's why I asked which set of parameters you see... if its the
second then it kind of confirms this... if its the first, I'm confused!) 
The timing would have to be rather perfect though, so another good
question to ask is whether you see this consistently.  If you do, I would
tend to think something else is going on because it doesn't strike me as
likely that the timing would be that perfect every single time.

But again, this should only apply to a session-scoped form.  I can't see
how it could possibly happen for request-scoped forms.

> original code:
> --------
>         ActionForm form = processActionForm(request, response, mapping);
>         processPopulate(request, response, form, mapping);
>            ...
>         // Call the Action instance itself
>         ActionForward forward =
>             processActionPerform(request, response,
>                                  action, form, mapping);
> --------
>
>
> modified code:
> --------
>        ActionForm form = processActionForm(request, response, mapping);
>        synchronized (form) {
>             processPopulate(request, response, form, mapping);
>                ...
>             // Call the Action instance itself
>             ActionForward forward =
>                 processActionPerform(request, response,
>                                      action, form, mapping);
>        }
> --------
>
> but I wonder if that's a good idea.

Well, except for performance considerations, I can't think of any reason
it would be a bad idea.  You would hold up that second request, and any
others that need the same form (which probably would only happen if you
had multiple windows open), so if that is a normal function of your
application then it might not be desirable.  Otherwise, it doesn't strike
me as a problem per se.

> Am I missing something here? Is there a way to ensure that the action is
> called each time with the set of parameters it was supposed to receive?

Make sure the forms a request-scoped.  But, aside from all the
Struts-specific aspects, I'd first be asking if this is a situation that
you should be disallowing in the first place... are these POSTs being made
as a result of some scripting or by users clicking things?  In either
case, my first suggestion would be some script that makes this never
happen in the first place (I'm assuming it isn't a requirement here).

> Thank you for any information!

Hope it helps! :)

> Best regards,
>         Arnaud

Frank


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Action Framework: simultaneous requests on the same path, in the same session.

Posted by Arnaud Diederen <ad...@ionicsoft.com>.
Frank W. Zammetti wrote:

Hi Frank,

> [...]
>
>But then again, this would only occur for session-scoped forms as
>request-scoped forms would be created anew with each request.
>  
>
Ahem.. I totally forgot about the scoping problem. Dunno why, but the 
ability to define forms as being request-scope or session scope 
_totally_ vanished from my mind.
Of course, just declaring the form bean as being request scope fixes the 
problem.

>[...]
>Without actually confirming any of this, what you describe seems logical. 
>With no concurrency control on the form object, the second request could
>theoretically occur at just the right time so as to overwrite the values
>in the form that the first request put there and only then is execute()
>called (that's why I asked which set of parameters you see... if its the
>second then it kind of confirms this... if its the first, I'm confused!) 
>The timing would have to be rather perfect though, so another good
>question to ask is whether you see this consistently.  
>
It was not consistent. It happened randomly.

>If you do, I would
>tend to think something else is going on because it doesn't strike me as
>likely that the timing would be that perfect every single time.
>
>But again, this should only apply to a session-scoped form.  I can't see
>how it could possibly happen for request-scoped forms.
>  
>
Indeed, it's nothing but a scope problem..

>Well, except for performance considerations, I can't think of any reason
>it would be a bad idea.  You would hold up that second request, and any
>others that need the same form (which probably would only happen if you
>had multiple windows open), so if that is a normal function of your
>application then it might not be desirable.  Otherwise, it doesn't strike
>me as a problem per se.
>
>[...]
>Hope it helps! :)
>  
>

It sure does! :)

Thank you and Joe Germuska for providing such quick help

Best regards,
        Arnaud





---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org