On 05/03/2011 19:30, lpxz wrote: It would of helped if you had mentioned which Tomcat version you were looking at. I'm assuming trunk.
> The expected semantic is > that the (service) invocation should use the instance of the most > up-to-date (servletClass). Where is that stated? My expectation is that at least the most recent servletClass at the point the service() method is called is used. If the source JSP is changed while the service() method is executing and the newer version is used, great. If not, it is not an issue. > However, the semantic is not preserved by > the original atomic regions due to atomicity violations: the retrieved > (servletClass) by the (getServlet) invocation may be stale as the > (servletClass) may be updated by the other thread since last (compile) > invocation. This is handled by the reload attribute. If thread 1 calls getServlet() before thread 2 sets reload=true that is fine. > Even if there is no buggy interleaving between the first > two invocations, there may be an interleaving write to (theServlet) > between the second and third invocation, which makes (theServlet) used > by the third invocation stale. If I have understood you correctly, then I think you have a point here. It would be better to store the return value of getServlet() and use that throughout the rest of the service() method rather than using theServlet. I'll get that fixed shortly. It will be in 7.0.11 onwards and I'll propose it for back-port to 6.0.x and 5.5.x as well (assuming they have the same issue). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
