why are struts Action classes not thread safe?

I can read in many websites that Struts Action classes are not thread safe . I am not开发者_如何学编程 able to understand why this is so .

Also I read a book which says "Struts action classes are cached and reused for performance optimization at the cost of having to implement the action classes in a thread-safe manner"

how is caching action classes and being thread safe related? .

How is caching action classes and being thread safe related?

If you cache and re-use instances of a class, allowing multiple threads to access the same instance simultaneously, then the class is inherently not thread-safe*. If you were to place mutable instance or static fields on the class, the results under concurrency would be unexpected and problematic. On the other hand, if each thread has its own instance of the class, then the class is inherently thread-safe.

• Struts 1 action classes are not thread-safe. You should not place any mutable fields on the class, instead using a Form Bean class for form fields passed to the action.
• Struts 2 action classes are thread-safe. New copies are instantiated for each request and placing instance fields on the class is a core concept in the framework.

* If the instance or static field is immutable, then its fine for multiple threads to access it simultaneously.

if any class is cached, and reused, there is a risk of corruption do to concurrent accesses by multiple threads. In a web application, every request is handled on a thread. Lets say you have 10 instances of an action, but your container is handling 20 requests -- in this case, your 10 actions are each being reused, because you have more requests in flight than actions available to service them.

The thread safety issue only rears its head if there is some state that is reused in the action. If that is the case, then an action that is servicing one request might set a value in the shared variable, but then another thread might take over, and the action might again modify the shared variable. In that case, when the original thread takes over, the shared state has been modified.

The easy way to deal with this is to configure your stack to just always use a new action, or make sure you have no shared state in your actions.

Why not create a new "action" object per request? What in the world??

Because Struts is so old, he thinks creating one more object per request cycle is as expensive as paying a dollar for a coffee. (that is, very expensive. because he's really old.)

Looking at the actual struts source, you'll see it just returns instantiated action classes back. so on, two requests can hit the same instance variable, creating a lot of problems if it's not synchronized correctly.

protected Action processActionCreate(HttpServletRequest request,
    HttpServletResponse response, ActionMapping mapping)
    throws IOException {

    // Acquire the Action instance we will be using (if there is one)
    String className = mapping.getType();

    Action instance;

    synchronized (actions) {
        // Return any existing Action instance of this class
        instance = (Action) actions.get(className);

        if (instance != null) {
            return (instance);
        }
   .......
    }
.....
}

While searching for a solution for this problem for an old Struts 1 project that was behaving randomly because of some ajax calls to the same action, I figured you can solve the thread safety problem for this case by using scope="request" on your struts-config.xml file.

<action path="/blabla" type="blabla" name="bla" scope="request">

Maybe this helps