When you use Tomcat as the Web application container, the session is not found for the new thread to be enabled

Today to do a function, in order to quickly respond to the front end, after the business is completed, another thread does not affect the business of the statistical work, and then immediately return the results of business operations to the foreground.

As a result, the request object is not found on the new line thread report null pointer. Under inspection, we use the STRUTS2 framework, which binds the request to the thread local variables in the struts2. Through the context of the serveltactioncontext can be taken. Then I will manually set the request into the context of the struts2 in the new line thread.

The request was found, but Request.getsession () was empty. It is strange that it is impossible to destroy the session in such a short time. found that if the original main line sleep, not so anxious to return to the front, there will be no such mistake. Speculation is what the container does when it completes the response, causing the request to find no associated session.

Look at Tomcat's source code and discover that his Httpresquest interface implementation Class Org.apache.catalina.connector.Request has a recycle method. As the name implies recycling, the context of this request is cleared, of course, there is no session. When this new request comes in, it is not created, it can be used directly to bind the stateless object to a new context, which is equivalent to the function of an object pool.

So the reason is that the main thread executes very quickly, when the main thread binding request is cleaned up and no longer associated with the session. Our newly created thread binds to the request object and cannot find the session after the main thread has finished. The workaround is simple, and the session is bound to the new thread with a thread-local variable.

When you use Tomcat as the Web application container, the session is not found for the new thread to be enabled