SRTServletRequest getSession(true) returns HttpSession with same sessionId

Question

I am facing issue with HttpRequest.getSession(true) - when called multiple times after invalidating session - this is returning session object with a new HashCode but same session Id.

Set up details -

JDK8 Websphere9.0 Application: Two wars: one with JSP Servlet based app, second one is Angular2 Spring based app Requirement: between two wars deployed inside same BLA EAR, need to share session, so using IBMApplicationSession for attribute get and set calls - all place HttpSession being used

If we are working on pages part of the JSP Servlet Jar app - the below code is able to create new session with a different session id

1.HttpSession session = request.getSession(false);
//few other lines
2.session.invalidate();
//few other lines
3.session = request.getSession(true);

i.e. the session at the end has a different session id than the session which we invalidated

However if we go to the another war which has Angular2 and spring based application - we create an instance of IBMapplicationSession to store attributes (get and set Attributes call) -- and then come back to the war which has JSP based application - the same lines of code is giving totally different and strange behavior - the third line is giving a different session object than one on line#1 (hash code is different) however sessionId remains same on the object

Application is dealing with the session based on sessionId - since sessionId remains same it is creating major trouble for us.

Can someone please help me know how come the session is being created with same ID even when I am calling request.getSession(true). TO be noted the Request implementation is SRTServletRequest part of websphere plugin com.ibm.ws.webcontainer jar

Thanks in advance for your suggestions

Answer 1

After a bit of research I found the below text - which helps me explain the nature of IBMApplicationSession

The benefit to using the IBMApplicationSession method is that each web module can maintain its own session and have a reference to the shared session. In other words, multiple requests from the clients, each specifying a unique web application, result in multiple sessions with a shared session ID. You can invalidate any of the sessions that share a session ID without affecting other sessions. If another web application has that session ID in use, new requests from the clients reuse the session ID. After all the sessions for the session ID are invalidated, and if no web application is using that session ID, new requests from the client do not reuse the session ID.

IBM link

In my case the session is still active (and we need to keep it active) in one application while going to second application and vice versa. So whenever we are trying to create a new session, SESSIONID remains same