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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
