struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Session invalidation problem
Date Mon, 08 Nov 2004 21:39:23 GMT
That's a good point, I forgot that.  I've added code to handle that situation.  I know that
wasn't it though based on the stack trace (the exception is thrown about 20 lines after the
check we're talking about), but I can imagine this might have come up too, so it made sense
to add.  Thanks Brian!

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

On Mon, November 8, 2004 4:06 pm, Barnett, Brian W. said:
> 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: []
> Sent: Monday, November 08, 2004 12:52 PM
> To:
> 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
> 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:
> For additional commands, e-mail:

View raw message