[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [servlet-dev] WebSocket and HttpSession
|
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
