DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40108>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40108 Summary: cross context includes don't reference correct session when page from differnt contect is included Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, Ive discovered a problem, that sessions are mixed, if the application makes cross context includes. Im using Tomcat 5.5.17. Here is the scenario: 1) Servlet A in context X wants to include page B from context Y and page C from context X; 2) Servlet A starts two threads to include page B and C; 3) Servlet A pass the request and response object to these threads and corresponding ServletContexts to context Y an Z (to get RequestDispatcher); 4) Each thread dispatches (using RequestDispatcher) to the corresponding page (B or C) 5) While in the page B and C these pages set and get attributes from the session object. According to Servlet spec 2.4 (SRV.7.3 Session Scope) if a servlet uses the RequestDispatcher to call a servlet in another Web application, any sessions created for and visible to the servlet being called must be different from those visible to the calling servlet. This means that the session in the different pages (B and C) must be different. However they are mixed sometimes B sees session for C and vice versa. The problem here is that one and the same request object is processed in two different threads simultaneously. Servlet specification does not forbid request object to be passed to multiple threads and to be processed concurrently by those threads. It just says that the application should wrap the request in order to synchronize the access to it. (Servlet spec 2.4 SRV.8.2) But in practice this is impossible. Wrapping the request only can ensure safe access but could not prevent changing of session. Ive checked the Tomcat sources. When a request has to be dispatched it is unwrap until container request object is reached. Then a new wrapper (ApplicationHttpRequest) is inserted there. This wrapper has the request parameters according the new context. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] When the second thread dispatches the request, it is again unwrapped and a new wrapper is inserted: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] This reflects the request in the first thread. As a result because [EMAIL PROTECTED] object is common the outermost wrappers will use one and the same [EMAIL PROTECTED] This is the cause for mixed session. Current implementation only works the first time the request is wrapped. But if it is wrapped several times (by some filters) this architecture will fail. I think that this has to be changed in order to allow the application to be able to process request in multiple threads in different contexts. Similar scenario is valid for JSR168 Portlet applications, when the portlets are depoyed as separate webapps. Then the portal can trigger multiple threads to render the portlets from the portal page. This is equivalent to the case where a single request is processed in different context in parallel. Regards, Diyan -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
