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

[Arnaud Diederen <ad...@ionicsoft.com>]

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 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.

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:

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.
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?

Thank you for any information!

Best regards,
        Arnaud

---------------------------------------------------------------------
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.

[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

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

["Frank W. Zammetti" <fz...@omnytex.com>]

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.

[Michael Jouravlev <jm...@gmail.com>]

On 1/18/06, Joe Germuska <Jo...@germuska.com> wrote:
> >but I wonder if that's a good idea.
> >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?
>
> If your forms are request scoped, there should be no problem; a new
> object would be created each time.
>
> If you must use session scoped forms, it's not so easy, as the
> "token" mechanism for dealing with "double-posts" is not automatic;
> you must invoke it from your action, which means that the
> population/corruption may have already happened.

Token is unrelated to this problem. Token prevents double submit (on
server level). What he has is "populate, populate, execute, execute"
instead of "populate, execute, populate, execute".

The synchronization is definetely in order, but on a session, not on a
form, I guess.

Michael.

---------------------------------------------------------------------
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.

[Joe Germuska <Jo...@Germuska.com>]

>but I wonder if that's a good idea.
>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?

If your forms are request scoped, there should be no problem; a new 
object would be created each time.

If you must use session scoped forms, it's not so easy, as the 
"token" mechanism for dealing with "double-posts" is not automatic; 
you must invoke it from your action, which means that the 
population/corruption may have already happened.

If you are actually using JavaScript to submit these forms, then I'd 
suggest adding some JavaScript which sets a "submitted" flag and 
tests it before actually causing a submit, setting it to true after 
it does submit.  I think that in a single page (not frame), things 
should be single-threaded so that this is relatively safe.

The other solution would be to extend the RequestProcessor to add a 
token validation step earlier than in the Action's execute() method. 
Actually, in Struts 1.3 this would be easier for all the reasons that 
Struts 1.3 makes changing the request processing path easier.  You 
could make a "validate token" command which would check the 
ActionMapping to see if it had been configured to "require valid 
token" (probably using Struts 1.3's "arbitrary config properties") 
and if that configuration had been set, you'd do the validation 
(which can be done using ActionContext), and if the validation 
failed, you'd probably fall back to using some other configuration 
property of the ActionMapping to determine the fallback action.

It actually seems like something which would be useful to add to the 
Struts 1.3 core, and perhaps even into the default chain. 
Unfortunately, I don't have time to code up something like that this 
month, but if you're interested, I can at least try to field basic 
questions here on the list (and hopefully so can others!)

The use of tokens in Struts 1.3 is probably something which could use 
a bit of a workout anyway; I can't remember why offhand, but I had 
some questions about how I adapted the processing model from Action 
to ActionContext and I haven't had an opportunity to really give that 
a workout myself.

Joe

-- 
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
	-- Robert Moog

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