On 17/12/2014 16:25, Greg Wilkins wrote:
>
> On 17 December 2014 at 12:46, Mark Thomas <markt_at_apache.org
> <mailto: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 don't see that as a race, I see that as the context changing as the
request is moved (as a result of calls by the application) between
servlet contexts. The async version of a cross-context dispatch.
> I do not think that getServletContext is an async safe method
I think it could be safe if the behaviour was well defined.
> - as you say, we really need to define these.
No argument there.
I think the broader discussions were are having in this thread and in
others on exactly what async means is useful. Once there is consensus on
that, defining the behaviour of the methods should be fairly simple.
> I think an async request leaves the scope of the context when the
> original synchronous thread leaves that context.
My concern with this interpretation is the following:
a) container thread A starts async on app thread B
b) the request is still within the scope of the context so app thread B
can access it
c) at some indeterminate point thread A exits the context
d) from this point on thread B is not within the scope of the context
and can not access it.
From thread B's perspective, it is within a context for a period and
then at some point it switches out. That doesn't seem safe either.
I like an earlier suggestion that calls to asyncContext.start(Runnable)
do not take effect until the container thread exists the context. That
solves a number of concurrency issues. Is there agreement on this? Is it
worth spinning this particular point out into a separate thread?
> 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.
Getting back to your original point which you expanded on above, I've
always though of the request remaining with the context associated with
the request when async started until it is moved to a different context
with a dispatch.
Mark