Hi,
On Fri, Nov 28, 2014 at 5:51 AM, Greg Wilkins <gregw_at_intalio.com> wrote:
> I think there are lots of problems with this, not least the object churn and
> wasted event notification.
> Should a session cookie be set?
No, of course not ;) Since a cookie is by definition used in a
follow-up request, and the idea was to scope the session to a single
request.
> What if generated HTML contains a href with the session ID encoded in the
> URL
In sessionless mode (which includes scoping the session to a request)
there won't be a session ID encoded to the URL, since pretty much the
entire idea is to not have sessions.
> and that causes the client to send a request before the generated HTML
> is fully generated (and thus the request is not finished). Will that
> request see the same session?
No
> if not why not?
Since the session is scoped to a single request and the client just
send a new request.
> If it does, when does the
> session get invalidated?
It doesn't, but the "session" gets invalidated at the end of the
request in which it was created. It would basically become a dependent
scope of the request scope.
> If it is a long polling application, there may
> never be a time when there is no request in the container and the session
> may live for a long time.
That's not different from having the request scope around is it? For
such particular request data stored as request attributes stick around
for a long time as well.
> HttpSession semantics are ropey enough without introducing such difficult
> racy transient invalidation.
There might well be conceptual issues, but race conditions should not
be among them, as that session scope will be local to a single request
thread, and will be seen and eventually invalidated by that thread,
and that thread only.
Kind regards,
Arjan
>
> cheers
>
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com> @ Webtide - an Intalio subsidiary
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
> http://www.webtide.com advice and support for jetty and cometd.