Craig,
Ok, let me get this straight: are you saying the problem is resolved with
2.1 compliant engines?
When I create a new session with WebSphere it creates a cookie that lasts
the life of my browser, or until a session timeout. The cookie is called
"sessionid". Certainly the session is maintained at a server level. What
I said to David before about web apps from different web servers causing
problems is false. The session id is a client to web server handshake, so
David's invalidates wouldn't affect my web apps. However, multiple web apps
from the same web server would affect each other.
My apologies for the confusion.
I can't find any good reading on the issue for 2.1 compliant engines.
Dan
> ----------
> From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
> Reply To: Craig McClanahan
> Sent: Monday, June 07, 1999 4:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: LIFESPAN=session and getSession()
>
> David Wall wrote:
>
> > > Keep in mind that invalidating the session prematurely is probably not
> a
> > > good habit to get into. Why? Because a session is tied to a browser
> > > session. If, like we are, you are creating multiple web apps that
> might
> > be
> > > used by the same user base, you could end up destroying session
> objects in
> > > one web app while the user is also in another web app, thereby,
> destroying
> > > those objects too. The same is true if your user is also working in
> my
> > web
> > > apps. If your web app invalidates the session, that screws up my web
> app
> > > too.
> > >
> > > Instead we let sessions timeout naturally, and work within objects we
> call
> > > application objects, or user objects, that we hang off the session
> object,
> > > and invalidate or destroy these instead.
> > >
> > > It isn't really a topic that gets discussed here, but I think it is a
> very
> > > important one. Invalidating the session is very bad form in my book.
> > >
> > > Cheers,
> > >
> > > Dan
> >
> > Wow! I really hadn't thought about it in these terms. Somehow I always
> > suspected a session was between a client's browser and my web site. In
> > fact, it still seems like that would be likely, since the servlet api is
> > overly brittle if we can affect others like that. For one thing, what
> does
> > it mean that my JRun engine puts a timeout on a session if that session
> is
> > really shared? Aren't sessions just fancy items based on a JRun
> specified
> > cookie (or via url rewriting if cookies are not there) that I'd presume
> is
> > tied to my web site and not yours?
> >
> > I was using the invalidate() only when a user is logging off of my web
> site
> > where they logged in during a session. I still cannot believe sessions
> are
> > in any way linked, and they certainly don't share state like objects
> within
> > as that would be insane and insecure.
> >
> > David
> >
>
> In a 2.1-compliant servlet engine, a session belongs to a particular
> ServletContext, not to the entire server. When the JSP spec talks about
> "application" scope, it is really talking about a ServletContext as well.
> Different applications should be installed in different ServletContexts.
>
> As long as you configure things correctly (don't use the same cookie name
> for
> both contexts, for example), there will be no difficulty at all in having
> a
> user be logging into and out of multiple applications with overlapping
> lifetimes. You can continue to invalidate a session as part of your
> normal
> logoff processing, without worrying about impacting that same user's
> current
> session with a different app -- whether that different app is on the same
> server or a different one does not matter.
>
> Craig McClanahan
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff JSP-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
