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.
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.
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.)
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.