I have a SessionManager which implements HttpSessionListener. In the SessionManager, I have a static hashtable of all active sessions. I am trying to create a function for forcing the invalidation of sessions. It looks something like :
HttpSession session = sessionRegistry.get(key);
session.invalidate();
That absolutely does what I want it to do, which is to destroy the targeted session. However, it seems to have a side effect on my @ConversationScoped managed bean.
In my ConversationBean, I have a property which holds some value. I just noticed that after invalidating a session from the sessionRegistry, the value stored on the ConversationBean gets destroyed.
- I was invalidating a different session (one from the sessionRegistry and not the current session)
- I printed the value from ConversationBean before and after invalidating the session and it is still there. It only gets destroyed once I leave the @ViewScoped page displaying the list of active sessions . (Caught it using @PreDestroy)
- Also, on the @PreDestroy annotated method of the @ViewScoped bean, I tried printing the Conversation Id and it is already nullified. And yes, the hash code for the ConversationBean is also different which means it a different instance from the one I had before invoking session.invalidate.
---- EDIT ------
This example demonstrates what I am trying to achieve :
Let's say I have an application scoped hashtable, sessionRegistry, with these values:
Key | Value
---------------------
1 | HttpSession1
2 | HttpSession2
3 | HttpSession3
I log in as an administrator. Now I believe I have a different session, let's say HttpSession4. I want to try to kick some session from the application scoped hashtable and I do it like this:
HttpSession session = sessionRegistry.get(1);
session.invalidate();
I destroyed HttpSession1 while I was logged in on HttpSession4. In my understanding, the conversation of HttpSession1 should be destroyed with it and not the current conversation, which should be associated with HttpSession4.
My question is, is this really a normal behavior of @ConversationScoped managed beans? It seemed to be associating itself on the session I was invalidating.