The servlet spec (see my previous question) guarantees that the same thread will execute all Filters and the associated Servlet. Given this, I do not see any use for passing data using HttpServletRequest.setAttribute if there is the option to use a ThreadLocal (assuming you clean up properly). I feel that there are two benefits to using ThreadLocal: type-safety and better performance because no string keys or maps are being used (except probably into a thread collection by (non-string) thread id).
Could someone please confirm if I am right so I can proceed with abandoning setAttribute?
Is ThreadLocal preferable to HttpServletRequest.setAttribute(“key”, “value”)?
Depends on the concrete functional requirement.
JSF, for example, stores the FacesContext in a ThreadLocal. This enables you to access all of the JSF artifacts, including the "raw" HttpServletRequest and HttpServletResponse anywhere in the code which is executed by the FacesServlet, such as managed beans. Most other Java based MVC frameworks follow the same example.
As per your comment,
I primarily need to transport the User and EntityManager objects from the user and database Filters to the Servlet. I also find that these are frequently and unexpectedly needed in code further down the line and I am tempted to use them well beyond the Servlet (i. e. in nested code called by doGet). I feel there may be a better way for deeper code - suggestions?
As to the User example for which I assume that this is a session attribute, I'd rather follow the same approach as JSF. Create a ThreadLocal<Context> where the Context is your custom wrapper class holding references to the current HttpServletRequest and maybe also HttpServletResponse so that you can access them anywhere down in your code. If necessary provide convenience methods to get among others the User directly from the Context class.
As to the EntityManager example, you could follow the same approach, but I'd personally not put it in the same ThreadLocal<Context>, but rather a different one. Or, better, just obtain it from JNDI in the service layer, which would allow you more finer grained control over transactions. In any case, please make absolutely sure that you handle the commit/close properly. Taking over the persistence and transaction management from the container should be done with extreme care. I'd really reconsider the aversion against using the existing and well-designed APIs/frameworks like EJB/JPA, otherwise you'll risk a complete waste of time of reinventing all the already-standardized APIs and stuffs.