My proposal is to add the following method to HttpSession:
public void access()
That may not be sufficient, because there are two states of a session that websockets needs to avoid: invalidation and passivation!
Having an access method could well prevent invalidation due to an idle timeout, but it will stop passivation if that is configured on the container. Typically a session is passivated some time interval after the active request count goes to 0. Often this timeout is much shorter than the idle timeout and we have some deployments that have a zero passivation timeout, so the session is passivated as soon as the last request exits the servlet container.
A passivated session will not be available to be accessed by a websocket endpoint.
There are further complications with websocket endpoint accessing sessions. For example, what is the dirty semantic? i.e. if the websocket endpoint modifies the session, then when are those changes persisted/distributed in the cluster? We HTTP request, we have commit and complete events on which we can flush a dirty session.
Session semantics is really poorly defined and barely sufficient for purpose for HTTP requests/responses. I've very dubious that it's semantics can be extended to websockets without creating some more horrid corner cases. Very careful thought is needed and I do not think there are any simple solutions.
regards
