Objects are not thread-safe - code is. HttpServletRequest objects are only safe to use in multiple threads if the code that handles them is. Since each incoming HTTP request is handled by a separate thread in the servlet container, each HSR object is safe unless your code starts using it in several threads (which would be an unusual way of doing things, but perfectly possible).
In extension, it's not quite correct to say that "HttpSession and context are not thread safe" - it depends on how the code that uses them does so. But it's certainly easier to write unsafe code since those objects are shared between threads to begin with (in contrast to HSR objects).
Ulf Dittmer wrote:Objects are not thread-safe - code is. HttpServletRequest objects are only safe to use in multiple threads if the code that handles them is..
This is not correct. The thread safeness of a class is absolute, it is not something depending on code context. It might not be official terminology, but it makes sense to call an object thread safe if it is an instance of a thread safe class. A class is either thread safe or it is not thread safe. Terminology for varying degree of "thread safeness" like conditionally thread safe and thread compatible has never acquired critical mass.
it depends on how the code that uses them does so
Again, rigorously, no. A class is either thread safe or not. Creating a not thread safe class based on existing thread safe ones does not make the original classes not thread safe.
[UD: fixed QUOTE tags]
Joined: Mar 22, 2005
Welcome to JavaRanch.
Luca Moretti wrote:The thread safeness of a class is absolute, it is not something depending on code context.
Talking about the thread-(un)safety of classes isn't very helpful here, since we're talking about interfaces for which the javadocs of the servlet API do not stipulate whether or not the implementing classes are supposed to be thread-safe. It makes sense to talk about uses of them that result in thread-safe code, and uses of them that result in thread-unsafe code; both exist. That certainly makes a difference in how those objects should be treated by code, and what measures may need to be taken in order to produce thread-safe code. That's why I mentioned only the thread-safety of code (and its usage of objects), not the thread-safety of classes.