Problem:
The Struts 2 Action object generates an instance for each request, so there is no thread safety issue.
Spring's IOC container-managed bean defaults to a single instance, the state information of the last request processing is persisted, and the next request is affected, in effect, the class variable in the action is read by a different request, and the error results occur
Workaround: Just do not use singleton, Spring beans scope is set to prototype, each request corresponds to one instance.
1, Struts1
Struts1 is a singleton pattern, that is, when the Web container (for example: Tomcat) is started, an action object is instantiated, and all requests are used for that object. So when there are 2 requests in parallel, then actually they are calling the same class, this time when you define the properties within the action, it will cause thread synchronization problems.
For example:
You define an int i = 0 in action;
This I is then manipulated in one of the methods inside the action. You will encounter problems when concurrency occurs.
So: We can't define attributes in action when we're using STRUTS1. To use only words can only be defined in the method.
2, Struts2
The Struts 2 Action object generates an instance for each request, so there is no thread safety issue. So we can define the attributes in the Struts2 action. But Struts2 because there is no difference between the action and the normal Java class (that is, you do not have to implement a struts interface like the one in Struts1, interested friends can get to know themselves), so we can use spring to manage the Struts2 action. , this time we have to pay attention, because when we are in spring to define the bean, spring by default is a singleton mode. So at this point, you need to modify the spring configuration file---that is, modify scope to prototype.
There is no threading problem in struts1 because all the code is written in the Execute method, all variables are defined inside, so there is no thread safety problem.
And now the STRUTS2 is not the same. Struts2 's action, like a Pojo, defines a lot of class variables. This is a thread-safe issue. At this point, the scope=prototype is used to specify a prototype pattern, not a singleton, which solves the thread-safety problem. Each thread is a new instance:
However, thread synchronization is a method that is not possible, is more complex, and can result in a loss of performance. In the equivalent code, there is no need for synchronization to be better at writing ease and performance.
What I'm emphasizing here is that the code is always thread-safe and does not need to be synchronized. As follows:
1) constants are always thread-safe because only read operations exist.
2) access to the constructor (the new operation) is thread-safe because each time a new instance is created, the shared resource is not accessed.
3) Most important: Local variables are thread-safe. Because each execution of a method creates a local variable in a separate space, it is not a shared resource. Local variables include the parameter variables of the method.
The Struts User Guide has:
Only with the local variables-the most important principle the AIDS in Thread-safe coding are to use only local Variables, no T instance variables, in your Action class.
Use only local variables. --the most important principle of writing thread-safe code is that only local variables are used in the action class and no instance variables are used.
STRUTS2 Thread-Safe
