why are struts Action classes not thread safe?

Question

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

Angelangela

where did you read this? – Ankney

This book – Angelangela

Just for insight that book was published March 31, 2007. Struts2 was released 2008. See: en.wikipedia.org/wiki/Apache_Struts#History ... Anyways S2 is a very different product from S1... just saying this to make sure you understand S1 and S2 are related only by name. – Swivet

I added the struts tag since this has become a sort of comparison of how action class instances differ between versions 1 and 2. – Bombardon

Answer 1

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.

Bombardon

Could you explain this concept of struts 1 and strut 2 difference with a nice working example – Coo

Answer 2

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.

Ankney

How do we configure the stack to always use a new action ? Is it possible to do so in struts 1 ? – Angelangela

Answer 3

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

Wisteria

Struts2 is not old. Here is a nice comparison table: struts.apache.org/2.0.14/docs/comparing-struts-1-and-2.html – Buttery

I think irreputable was referring to Struts 1, which is old. Agreed that Struts 2 is not old, though. – Bombardon

Absolutely! I just wrote the comment above, so that new programmers do not get a wrong impression about Struts. When we say "Struts" today, we mean Struts2 most of the time... – Buttery

Because of how bad Struts is to the reputation of Struts2, when writing I try to say "Struts2" and then use S2 for all future references. What a pain their naming choice was! – Swivet

Yeah, I agree. I wish it was still called WebWork. Whatever we call it, its a great framework. – Bombardon

Answer 4

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);
        }
   .......
    }
.....
}

Whitefish

Answer 5

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

Rhodium