Session.getAttribute(sessionAlive") will throw an IllegalStateException if
it is called against a session that is invalidated.
Try something like this:
try {
Session.getAttribute(sessionAlive");
} catch (IllegalStateException e) {
request.setAttribute("message", "Your session timed out. Please log on
again.");
// Don't call invalidate(), as it also throws an IllegalStateException when
// called against a session that is invalidated.
// session.invalidate();
return mapping.findForward("reload");
}
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, November 08, 2004 12:52 PM
To: [EMAIL PROTECTED]
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
