tomcat 4 and sessions - clear as mud

[Ja...@clev.frb.org]

Hi all,

I am struggling to understand how Tomcat 4 creates and invalidates
sessions. In the app I'm writing, I used to use a straightforward method of
inserting a String into the session when the user was logged in, and
removing it when the user logged out. This was only a work-around for the
fact that I could never seem to get an invalid session object as expected.
I decided today to revisit my code, and rewrite it according to how I think
it should work. I'm not having any luck though, and this is driving me
crazy. Can somebody explain this to me? Here are some servlet code
fragments:

      // logon code
      // Make sure the user is not logging in twice
      HttpSession session = request.getSession(true);
      if (session.isNew() == false) {
            session.invalidate();
            session = request.getSession(true);
      }

This is straight out of the current issue of JDJ, actually. (I'd not used
isNew() before.) Now for the logoff:

      // logoff code
      // destroy this user's session
      HttpSession session = request.getSession(false);

      if (session != null) {
            // remove the user object from the session
                  session.removeAttribute(Constants.USER_KEY);
                    session.invalidate();
      } else
            debug("No session object available for this user.");


One interesting thing I noticed is that, during logoff, I often get handed
a session from Tomcat, despite the getSession(false). This is supposed to
return either a valid session or null; but I usually get a
org.apache.catalina.session.StandardSessionFacade -- even if I logoff
twice, and the session.invalidate() has been called!

Then my logon code is subject to a similar issue. Even though I've just
called session.invalidate() in my logoff code, my next logon is not
recognizing my created session as a new one. Shouldn't it be new since I
just called invalidate?

I've poured through the archives, and many people have described a similar
issue to this, but I've not seen a satisfactory solution (except for an old
post of Craig's, which endorsed the String stored in a session).

Clarification of these issues would be appreciated. Thanks for any help.

--Jason




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>