request.isRequestedSessionIdValid does not work

[kenzhang]

Hi all,

During my work, I use request.isRequestedSessionIdValid to check whether the session is valid before I invalidate one session, the code is like below:

if (request.isRequestedSessionIdValid()){
 session.invalidate();
 }

However, those codes do not always work correctly. Sometimes, there will be IllegalStateException caused by the 'session.invalidate', the stack trace is like below:

java.lang.IllegalStateException: invalidate: Session already invalidated
at org.jboss.web.tomcat.service.session.ClusteredSession.invalidate(ClusteredSession.java:669)
at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:150)

.

Can anybody tell me why?
Thanks in advance.

BTW: while doing the search across the forum, I find one post which covered the similar issue:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135699,
but unfortunately, there is no reply for that post.

[kjkoster]

Dear kenzhang,

I am just guessing here, but could it be caused by two cluster nodes each trying to invalidate the session?

Kees Jan

[kenzhang]

Hi Kees,

Thanks for your reply. But the situation that 'two cluster node each invalidate the session' should not happen in my case.
We do use JBoss cluster, but we enforce that session will be bound to one cluster node for ever.

I have another guess (though somewhat absurd) that: session and request may not always bound together, and the session used in

session.invalidate

is not the request session, and hence, not the session used in

request.isRequestedSessionIdValid()

[kjkoster]

Dear kenzhang,

Why not work around this issue as follows:

try {
 session.invalidate();
} catch (IllegalStateException e) {
 // yeah, yeah.
}

The effect is that after this statement block the session is invalidated, regardless of whether it was before the block.

[kenzhang]

Hi Kess,

Thanks for the suggestion.
Yes of course that's one good work around, and I think most people will use that work around to get their work go on.

But I just wonder the root cause......
there should be something/implementation about request and session that we do not know lying there and worth our discussion and thinking.

Thanks all the same.