tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Qin <Phillip....@shareowner.com>
Subject RE: Session invalidation problem
Date Mon, 08 Nov 2004 19:57:07 GMT
Have you tried session.isNew()?

-----Original Message-----
From: fzlists@omnytex.com [mailto:fzlists@omnytex.com] 
Sent: November 8, 2004 2:52 PM
To: tomcat-user@jakarta.apache.org
Subject: Session invalidation problem


Hello all.  I'm cross-posting this to the Tomcat and Struts lists because
I'm not sure where is more appropriate to post it.

I have an application that is throwing the following sporadic, but
thankfully infrequent, exceptions:

stack trace: java.lang.illegalstateexception: setattribute: session already
invalidated

It is on a call to session.setAttribute().  Here's the weird part... Just
before that method call I do the following:

if (session == null || session.getAttribute("sessionAlive") == null) {
  request.setAttribute("message", "Your session timed out.  Please log on
again.");
  session.invalidate();
  return mapping.findForward("reload");
}

The idea of course is to tell the user their session timed out.  Now, as I
understand it, the session==null portion will always be false because
session is never null, there is always a session associated with the
request, even if it's empty.  That's the reason I put the sessionAlive
attribute in during logon and check if THAT is null with each subsequent
request to indicate whether the session has timed out or not (please keep
the comments about this not being done in the typical way to a minimum...
this is an inherited app I'm dealing with).

Any idea why I might still be seeing that exception?  The verbiage of it is
a little odd and doesn't seem to make sense, especially considering the
check right before that is indicating the session is fine.  I guess it COULD
be timing out between that first check and the call to setAttribute(), but
I'm assuming the container wouldn't invalidate a session that is attached to
a live request, logically that would make sense, so I've more or less
discounted this possibility.  I appreciate any thoughts you may have!

Frank W. Zammetti


!DSPAM:418fce80320296137119042!

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message