Question

I understand that Struts2 Action classes are thread-safe, because the actions are put in the Value Stack. The Value Stack in turn is one part of the Action Context. Since the Action Context is thread-local, the values stored in the Action Context (including the value stack) are unique per thread. So, Actions are thread-safe.

But consider the interceptors: They are really useful, they do all those tedious little jobs for the programmer… like validations, fetching the param values, etc. But the thing to consider is that: Interceptors can be shared between multiple requests. So does that make interceptors thread unsafe?

With this question in mind, I tried to surf the net for some good articles related to this problem. And I found a very good article, where they have clearly mentioned with an example How interceptors are NOT thread safe.

The web page is: http://www.bullraider.com/java/struts2/tutorials/interceptors-and-thread-safety

What I got to know from this article is, the major reason behind Interceptors being thread un-safe is that the interceptors are created only once. i.e. each interceptor has only one object. So, the instance fields are not safe, when the same instance of an Interceptor is shared between threads.

At the end of the article it’s mentioned that there are cases, where even the interceptors are thread safe. But they didn’t mentioned any such cases. I surfed the net to find the answer… but in vain 🙁

Can anybody tell me or provide me with a link, where I can find out how to make interceptors thread-safe (or what are the scenarios when an interceptor is thread safe)?

Answer 1

Any Interceptor that does not use instance fields or other shared state is thread-safe:

For examples, look at all the built-in interceptors that parse HTTP request parameters and cookies, do logging, access checks, exception handling: They do not use instance fields for mutable state(*) but just operate on the ActionInvocation instance they get as parameters.

(*) some do have instance fields for configuration parameters which are set when Struts starts up (in a single thread), like ExceptionMappingInterceptor, or thread-safe instance fields like the Logger in LoggingInterceptor.

If you plan on writing your own Interceptor, work just with the ActionInvocation parameter you get passed in and with local variables in your intercept() method. Avoid the temptation to make your intercept method synchronized or put things into a synchronized{} block — this will create a bottleneck with Struts’ single-instance approach to Interceptors.

To answer the questions from the comments:

(1) How come creating an instance of action for every thread doesn’t affect the performance?or does it?

With modern JVMs, the cost of creating an object is negligible. There should be no noticeable effect on performance if you keep your actions light-weight by avoiding expensive initializtion, e.g. by not creating database connections inside an action but using a connection pool.

(2) Do u recommend NEVER to use the default interceptor stack, and always use custom interceptor stack (where all the unused interceptors which use instance variables are removed) so that it will be thread safe?

I don’t think any of the default interceptors that are shipped and configured with Struts 2 are not thread-safe; even if they use instance fields (because they’re either used for configuration only or itself thread-safe like Logger).

From my personal experience, you should only ever touch/change the interceptor stack if you have a good reason (thread-safety of the built-in interceptors isn’t one). A lot of things behave/break in unexpected ways if you change the stacks — running one of the built-in stacks like “default” or “paramPrepareParam” saves a lot of frustration in the long run. Adding your own custom interceptors is usually less disruptive than removing/rearranging interceptors from an existing stack.