Mark,
Something like that might be possible, but I don't really don't like many aspects of this proposal.
The Session object returned from request.getSession was never intended to be used beyond the scope of the request lifecycle. Putting startAccess/endAccess on the session API would be problematic for several of our implementations as we really don't like objects that have been passivated suddenly becoming active again. Doing so is just asking for races! Nor are all our implementations intended to be shared between multiple requests, let alone other threads. Thus I think the API needs to be on something else other than the session.
Applications can call unmatched endAccess. It would be far better to have something like access(Consumer<Session>) that could be called with the activated session. Hmmm but that is blocking. Maybe something like access(BiConsumer<Session, Runnable>, with the Runnable being the end event.
All in all, session semantics are poorly defined enough for incoming HTTP requests, without adding this complication.
Actually that might be a better solution: let websocket use actual HTTP requests sent over a local connector to hit the application normally, so all normal session semantics will apply. I.e. we should provide a simple way to create locally HTTP invocations.