Mark, Stuart,
Thus I do not think it would be good to suddenly after all these decades, suddenly say that it is OK to keep request and/or session references beyond the end of the request lifecycle. Doing so is not going to just break "one container", but many applications/frameworks/deployments that have extended containers based on the non reference assumption.
This would definitely break WildFly/EAP clustering (attempting to use the session outside the scope of a request).
We could potentially just make this method optional, and allow containers to not implement it, or only support it for some session configurations. I don't think we would want to support this for clustered sessions in WildFly, clustering is complex and something like this would just add additional code paths that likely won't get the same level of testing as the main clustering code paths.
The other issue with clusters is that a response to a client is in a race with any subsequent requests that may end up on another cluster.
For this reason, with a normal HTTP request accessing a session, we always flush the session to any persistent store/ (or distributed cache) as part of committing the response, so that if a subsequent request turns up on another node on the cluster before the current request handling is complete (happens more often than you'd think), the session is already updated.
So for any mechanism to avoid the same issue in websockets, then during any access call, no websocket messages should be sent that depend on any mutated values in the session. I guess that is just javadoc.
Another option would be for the Consumer<Consumer<Session>> Session.getAccessor() method to have the options of:
- returning null if not supported
- calling the inner consumer with a read only version of the session if mutation is not supported
- calling the inner consumer with a full version of the session.
cheers
