| Re: [servlet-dev] WebSocket and HttpSession |
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.On Mon, 12 Jun 2023 at 12:38, Mark Thomas <markt@xxxxxxxxxx> wrote:On 09/06/2023 18:34, Greg Wilkins wrote:
> On Thu, 8 Jun 2023 at 17:58, Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>> wrote:
>
>
> 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!
I agree the proposal will not be sufficient for all scenarios. However,
if it is sufficient for some scenarios then I think it is worth considering.
> 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.
I agree a complete solution may not be simple. I'm happy to look at the
wider problem (we have a number of open issues against the Servlet spec
for those) but I'd also like to make progress on this WebSocket issue if
we can.
I'm not sure I like it but something that could work would be two methods:
public void startAccess()
public void endAccess()
These would be intended for non-HTTP based application components (e.g.
WebSocket) to work with the session. Roughly (details to be fleshed out
if the principal is acceptable):
- startAccess()
- container treats it as the start of an HTTP request
- active request count is incremented
- last access time is updated
- endAccess()
- container treats it as the start of an HTTP request
- active request count is incremented
- changes to the session are distributed/persisted
The idea being that if WebSocket (or anything else) wants to update the
session it needs to do so between startAccess() and endAccess().
Mark
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
--_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev