Jetty has this functionality where it can evict idle HttpSession objects out of memory and persist them on disk (passivation). Once a new request arrives with the same session id, it'll be brought back into memory (activation).
Jetty 9.2 and 9.3 source code for HashSessionManager and HashedSession reveals that the actual HttpSession instances are not discarded during idle eviction process but merely the attributes within them are cleared.
That tells me it is safe to keep a reference to a HttpsSession for a period longer than its active lifespan. And that I should not be worried about having a duplicate of the same session after it is de-idled.
I'm curious to know whether this is a standard behavior of all web server implementations. I could not find any documentation confirming that. Since session management is completely rewritten in jetty 9.4, is it true there as well?
The HttpSession you access from a HttpServletRequest is only garunteed to be valid for the duration of the Http exchange, once your request is processed, and a response is produced, and the request dispatch is completed, the specific HttpSession instance you accessed is now invalid, and recycled.
It is highly unwise to hold onto it beyond that timeframe, as the object, and its information could be recycled (from an object pool) into a different request/response for a different user.
WebSocket is another animal.
Once the HTTP connection is upgraded to WebSocket, all of the HTTP specific information is invalid.
Why? That's because WebSocket is not HTTP, and the Upgrade stops/terminates the active HTTP exchange.
The implementation in Jetty will recycle the HttpServletRequest, HttpServletResponse, and HttpSession at the point of the upgrade for use on a later HTTP request.
Also of note, the context, lifetime, and lifecycle of the HttpServletRequest, HttpServletResponse, and HttpSession are not defined in the Servlet spec, or the CDI spec. Meaning that if you use/require those objects in a WebSocket, know that you have entered into undefined behavior. It would be wise to copy the information you need from those objects for your WebSocket endpoint to use.