If you use Spring, must your component classes (@Controller, @Service, @Repository) be thread safe? Or does Spring use them in a thread-safe manner so you don't have to worry about thread safety?
That is, if I have a @RequestMapping method in my @Controller, could that method be called simultaneously for the same controller object by more than one thread?
(This has sort-of been asked before, but not answered as such).
Given
@Controller
public class MyController {
@RequestMapping(value = "/index")
public String respond() {
return "index";
}
}
Spring will create an instance of MyController. This is because Spring parses your configuration, <mvc:annotation-driven>, sees @Controller (which is like @Component) and instantiates the annotated class. Because it sees @RequestMapping as well, it generates a HandlerMapping for it, see the docs here.
Any HTTP requests the DispatcherServlet receives will be dispatched to this controller instance through the HandlerMapping registered before, calling respond() through java reflection on that instance.
If you have instance fields like
@Controller
public class MyController {
private int count = 0;
@RequestMapping(value = "/index")
public String respond() {
count++;
return "index";
}
}
count would be a hazard, because it might be modified by many threads and changes to it might be lost.
You need to understand how Servlet containers work. The container instantiates one instance of your Spring MVC DispatcherServlet. The container also manages a pool of Threads which it uses to respond to connections, ie. HTTP requests. When such a request arrives, the container picks a Thread from the pool and, within that Thread, executes the service() method on the DispatcherServlet which dispatches to the correct @Controller instance that Spring registered for you (from your configuration).
So YES, Spring MVC classes must be thread safe. You can do this by playing with different scopes for your class instance fields or just having local variables instead. Failing that, you'll need to add appropriate synchronization around critical sections in your code.
By default, controllers are singletons and thus must be thread-safe. However, you can configure the controllers to be request or session scoped, i.e.:
@Controller
@Scope("session")
public class MyController {
...
}
Controllers with session scope can be helpful for managing session state. A good description of different patterns can be found in Using Sessions in Spring-MVC (including "scoped-proxies") and in How to get Session Object In Spring MVC. Some of the presented patterns require request scope.
The request scope is useful as well if you have data that you cannot afford to calculate more than one per request.
Yes, of course.
It's best if those are stateless, which makes them thread safe by default. If there's no shared, mutable state there's no problem.
Basically the answer should be yes and no. Except to very serious reason. Not because Spring synchronizes work for you- it does not do it(by default a Controller is a Singleton bean). Of coarse a thread safety must be kept along a method call, but normally mechanism of Servlets wipes out necessity to synchronize something, because a request executed inside a thread. So,during a call of any @RequestMapping annotated method the whole call stack executed in one thread. In the root it is outgoing from the service-do(Get, Post..) methods of a Servlet and then handlers map acted, which Spring builds (see http://www.studytrails.com/frameworks/spring/spring-mvc-handler-mappings/ http://technicalstack.com/dispatcher-servlethandlermapping-controller/ for example). Spring calls handling method from map of handlers, after URL has resolved. No other tricks. So think, you work inside a doPost(...) for instance method of DispatchServlet. Is a Servlet thread safe? No of coarse. Can you do it thread safe-yes, use locks, synchronized, what else and make your Servlet to be a bottleneck! Exactly the same is about controller. A doGet/Post/what else method of Servlet has basically a functional model, all data are in HttpServletRequest object. The same manner should be used in Controller object- used data classes, and stack instead of fields. You can synchronize access to them, but by paying price of bottleneck. Of coarse you can use atomics, by is it so needed? If you need to keep any state during session, you can use @Scope("session") after @Controller or (for singleton controller) a handler method with signature (..., HttpSession) both of them has pro and cons. But note, that you created additional CPU and GC expenses. Anyway, you are responsible for Controller thread safety when you want to use fields and exit from concept of stateless. Normally a cache (redis for instance) is preferable for a client state keep. At least you can restore state when a failure occurred. Stateful controllers out of session scope basically have no reason.
