> 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
===========================================================================
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".
