On 01/01/2015 10:50, Greg Wilkins wrote:
>
> Mark,
>
> Looks like us two are at least converging.
>
> I hear you comments about threadlocals, and while I agree that they are
> a poor mechanism, they are still used moderately extensively, so we have
> to be careful regardless.
>
> I also agree that we do have many existing issues that threads can call
> service directly themselves. However, the text that Shing Wai has
> highlighted already kind of prohibits this as it describes a single
> thread calling sequence, which another thread calling service would break.
Agreed. I only wonder if the text from the last sentence of 6.2.3 should
not be moved/repeated elsewhere as it is fairly fundamental and seems a
little buried in the weeds at the moment.
> But that is not something we can inforce because essentially a thread
> calling service is a call from application code to application code
> without even the opportunity for the container to intervene. Calling
> doFilter is a call into the container requesting it to continue calling
> an opaque filter chain and eventually the servlet. Thus between caller
> and target the container is involved and may invoke other code that the
> caller and target are unaware of.
Agreed.
> But rather than try to restrict what threads can call service, let's
> just define what APIs are valid for what threads.
>
> We essentially have 3 classes of calling environments: Container
> dispatched threads, Container anointed thread (ones within
> AsyncContext.start()) and other threads. We need to define what
> methods can be called from which contexts.
>
> Basically we need to go through the API and work out which methods are
> safe to call from an async thread (eg. Request attributes, Response
> setHeader, flushBuffer, getOutputStream, etc.); which can be called
> from an anointed thread (EJBs?, JNDI?); and which are only valid from a
> container dispatched thread (eg request getServletContext,
> getRequestDispatcher etc.)
Sounds reasonable to me.
Mark