I hadn't thought of that, but it's an interesting thought... I guess the least intrusive way would be to add it to the IF statement... i.e., check if the session is null (which should always be false, but I'm anal so what the hell), check is sessionAlive is null, and check if session it's new... If any of those are true, the session has timed out. Interesting thought, I think I'll give that a shot. Thanks a lot Phillip!
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, November 8, 2004 2:57 pm, Phillip Qin said: > Have you tried session.isNew()? > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: November 8, 2004 2: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 > > > !DSPAM:418fce80320296137119042! >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
