On 5 August 2012 19:05, Mark Thomas <mark_at_homeinbox.net> wrote:
> The question this raises for me is what is the mechanism going to be for
> retaining state? i.e. what is the WebSocket equivalent of HttpSession
> going to be? The follow-on question is how is state information
> transferred between the WebSocketSession (for want of a better name
> right now) and the HttpSession.
In my websocket work to date, having websocket session has not been an
issue as we create an EndPoint per connection as a new object that can
hold state.
It is only if we go to a servlet-like model where we have the one
precreated instance of an endpoint handler that is handling multiple
connections that we have the problem of state. I think it is best
to avoid doing this and thus avoid the need for having a session
object (with all the poor concurrency semantics that the servlet
session has).
> Currently, my thinking is use the MessageListener to hold any necessary
> state and expose the HttpSession to it. That then raises the question of
> how to keep the HttpSession alive if there is a period of time greater
> than the session expiry time where there is only WebSocket traffic? Does
> the HttpSession expire or do we need to place a requirement on the
> Servlet EG to provide a mechanism to enable us to 'touch' the
> HttpSession to keep it alive?
As a lot of authentication mechanisms are tied to the session, I think
we probably need a way to touch the session and keep it alive.
cheers
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.