On 17 December 2014 at 12:46, Mark Thomas <markt_at_apache.org> wrote:
>
> Given that you can call
> request.getServletContext() and get the ServletContext it seems wrong to
> say that the request has left the scope of the web application.
>
Mark,
I don't think you can asynchronously call getServletContext and get "the"
ServletContext.
In the above example, at various times getServletContext must return A, B
and C, so an asynchronous thread calling that method will be in a race and
will see different values at different times. I do not think that
getServletContext is an async safe method - as you say, we really need to
define these.
I think an async request leaves the scope of the context when the original
synchronous thread leaves that context.
More importantly, I think that an async request that no longer has a
synchronous dispatch within the scope of a context has not context at
all. The async request only re-enters the scope of a context when
dispatch is called and then it may be one of 3 different scopes that it may
enter:
1. If startAsync(request,response) was used, then dispatch() or
dispatch(path) will cause the request to enter the scope of the context
that called startAsync
2. if startAsync() was used, then dispatch() or dispatch(path) will
cause the request to enter the scope of the normally mapped context
3. if dispatch(context,path) is used, then the request will enter the
cope of the passed context.
Given that the scope an asynchronous request enters after dispatch may be
different from the scope it was in when async started, then I don't think
it is meaningful to say the synchronous scopes persist during async
handling.
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.