struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Is MappingDispatchAction (Struts?) multithreaded? (Do I need to worry about it?)
Date Sun, 02 May 2004 03:44:23 GMT
Riyad Kalla wrote:

> Can anyone answer this? (DEVs) I'm very interested in the answer...

Most of the aspects in which you have to worry about thread safety in 
Struts mirror those you have to be concerned with in servlets.  In the 
particular case of MapDispatchAction, though, there is nothing really 
special about it (in terms of thread safety) versus any other Action.

Struts creates one instance of an Action per <action> element in a 
struts-config.xml file.  If there are multiple simultaneous requests to 
the same action (very common in an app with lots of users), then you do 
indeed need to care about this.

The most important rule -- again, this relates to *all* Actions, not 
just MDAs -- is to *never* use instance variables in the Action class to 
store information related to the state of a particular request.  
Instead, you should use local variables inside your methods, and pass 
whatever data you need to other methods in the class via parameters.  
Why?  Because local variables and method parameters exist once per 
*thread* instead of once per *instance*, so there is no problem in using 
them to store the state for a particular request.

Thus, you are definitely correct in being concerned about thread safety 
of the proposed code.  If the "actionMessages" variable is coded as an 
instance variable of the MDA, it will be updated by all simultaneous 
requests to the same action (it only takes two simultaneous requests to 
ruin your day).  You'll want to come up with some mechanism that passes 
all the necessary data as parameters, and not rely on instance variables.

Craig McClanahan

> Riyad Kalla wrote:
>> Let me clarify:
>> The first sentence should read "and almost all of my METHODS in my 
>> MDA's do some form of...", so my question is pertaining to any danger 
>> I have when 2+ methods of the same MDA gets called at the same time 
>> and all of them want to return errors.
>> Also the subject had "Struts" in it, because I'm not sure if this is 
>> a "is Struts thread safe?" question or a "Does my servlet container 
>> determine if something is thread safe? And if so, is Struts?". So I'm 
>> not real clear on what takes care of threading, but I know the 
>> use-case I want and I'm curious if anyone knows if its not safe.
>> Best,
>> Riyad
>> Riyad Kalla wrote:
>>> I'm asking because I am now getting into MappingDispatchActions 
>>> (MDA), and almost all of my actions do some form of DB validation 
>>> and error out if something goes wrong. So I have stamped all over 
>>> the place 4 lines of code that look like:
>>> ActionMessages actionMessages = new ActionMessages();
>>> actionMessages.add(ActionMessages.GLOBAL_MESSAGE, new 
>>> ActionMessage("product.error.cannotMove"));
>>> saveErrors(request, actionMessages);
>>> return mapping.findForward("failure");
>>> And I was thinking how nice, performance and organization if I could 
>>> move a protected instance or even utility method into a base 
>>> AbstractMappingDispatchAction class that did those 4 steps for me 
>>> and I just passed in the message key....
>>> So the method would do something like:
>>> actionMessages.clear();
>>> actionMessages.add(ActionMessages.GLOBAL_MESSAGE, new 
>>> ActionMessage(messageKey));
>>> saveErrors(request, actionMessages);
>>> return mapping.findForward(forwardName);
>>> but then I realized that this could be a huge problem if I had (a) a 
>>> lot of users using the system and (b) struts/servlet container was 
>>> multithreaded and called 2 methods at the same time that BOTH had 
>>> errors... I could run into a situation where one method cleared the 
>>> errors that the other method was trying to return to the user 
>>> because the actionMessages instance is shared per-class.
>>> Can anyone let me know if my worry IS correct and I should keep 
>>> everything the way it is, or if I'm safe and can go ahead with it, 
>>> and "why", if you know.
>>> Thanks!
>>> Riyad
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message