Hi, Ahh, good. I didn't consider that use-case, and it's evil indeed. Thank you for pointing that out. Option 2 seems better as you suggested.
Yoav --- Jan Luehe <[EMAIL PROTECTED]> wrote: > Hi Yoav, > > Yoav Shapira wrote On 10/12/05 19:38,: > > Hi, > > I don't want to chop off any parts of your email because it nicely > establishes > > the context for the question, so I'll leave it all below. > > Thanks! > > > It's not obvious to me that option #1 is not acceptable. It raises the bar > on > > the includer, perhaps, but it's not obviously unacceptable. Am I missing > some > > relevant portion of the Servlet Spec here? > > No. I agree Option 1 raises the bar on the includer, but not every > includer may be aware of it. > > If only the includer needed to be aware of this, Option 1 may not be > so unacceptable, but in the case where the includer issues multiple > RD.include() operations in parallel, the issue becomes more serious. > > For example, the portal server (webapp) simultaneosuly executes several > portlets (from different webapps) aggregated on a portal page, by > spawning as many threads and having each thread perform a RD.include() > to the target portlet. > > If any of the portlets acquire a session, invalidate it, and then > request a new session, Option 1 would require not only the session in > the origin context, but any session in any of the other portlets to be > invalidated as well, because the session in the origin context and the > sessions in the target (portlet) contexts all share the same id. > > With Option 2, neither the session in the origin context nor the > sessions in any of the other portlets would be affected. > > > Jan > > > > > > Yoav > > > > --- Jan Luehe <[EMAIL PROTECTED]> wrote: > > > > > >>I have a question regarding session invalidation in the target context > >>of a RequestDispatcher.include(). > >> > >>Some background info: The current impl of package > >>org.apache.catalina.core.ApplicationHttpRequest.getSession() creates a > >>session in the target context of a RD.include() as follows: > >> > >>- Checks if the origin context has any active session. > >>- If the origin context has no active session, creates a session in > >> the origin context. > >>- Creates a session in the target context, and assigns to it the > >> id of the session in the origin context. > >> > >>The requirement of having the sessions in the origin and target > >>contexts share the same session id is due to the fact that any context > >>that is the target of a RD.include() must not change any of the > >>response headers (and therefore must not add any Set-Cookie response > >>header) as per the Servlet Spec (SRV.8.3). > >> > >>This approach has worked well - as long as the target context > >>does not decide to invalidate its session and acquire a new > >>session. In that scenario, the current impl returns the invalidated > >>session as the new session, causing IllegalStateException to be thrown > >>when the session is accessed. This is because we currently don't > >>check if "localSession", which is assigned as follows: > >> > >> localSession = context.getManager().findSession(other.getId()); > >> > >>is valid before returning it. > >> > >>We can easily fix this so that the invalidated session is no longer > >>returned, but what should the newly generated session look like? > >>I can see the following options: > >> > >>If the target context invalidates its session and then requests a new > >>session .... > >> > >>- OPTION 1: > >> > >> ... we also invalidate the session in the origin context, create > >> a new session in the origin context, create a new session in the > >> target context, and assign the id of the new session in the origin > >> context to the new session in the target context. Obviously, this > >> option is unacceptable as it destroys any session data in the origin > >> context. > >> > >>- OPTION 2: > >> > >> ... in the target context, we purge the invalidated session immediately > >> before creating a new session and assigning to it the session id > >> of the invalidated session (which is still equal to the id of the > >> session in the origin context). This approach would violate the > >> uniqueness requirement of session ids per context, but I don't see > >> this as a problem, because this is happening within the same request. > >> > >> > >>Any other opinions? > >> > >> > >>Thanks, > >> > >> > >>Jan > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
