tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40108] New: - cross context includes don't reference correct session when page from differnt contect is included
Date Tue, 25 Jul 2006 12:13:24 GMT
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: diyan.yordanov@gmail.com


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.

HttpServletRequestWrapper@be49e0
HttpServletRequestWrapper@8b8a47
ApplicationHttpRequest@e41bc3
RequestFacade@1682598

When the second thread dispatches the request, it is again unwrapped and a new 
wrapper is inserted:

HttpServletRequestWrapper@4204
HttpServletRequestWrapper@8b8a47
ApplicationHttpRequest@1bb9a58
ApplicationHttpRequest@e41bc3
RequestFacade@1682598

This reflects the request in the first thread.

As a result because HttpServletRequestWrapper@8b8a47 object is common the 
outermost wrappers will use one and the same ApplicationHttpRequest@1bb9a58. 
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message