Servlet 3 spec and ThreadLocal

Async processing shouldn't bother you unless you explcitly ask for it.

For example, request can't be made async if servlet or any of filters in request's filter chain is not marked with <async-supported>true</async-supported>. Therefore, you can still use regular practices for regular requests.

Of couse, if you actually need async processing, you need to use appropriate practices. Basically, when request is processed asynchronously, its processing is broken into parts. These parts don't share thread-local state, however, you can still use thread-local state inside each of that parts, though you have to manage the state manually between the parts.

(Caveat: I've not read the Servlet 3 spec in detail, so I cannot say for sure that the spec says what you think it does. I'm just assuming that it does ...)

Am I correct to assume that ThreadLocal will cease to be a convenient hack to keep the request data?

Using ThreadLocal was always a poor approach, because you always ran the risk that information would leak when a worker thread finished one request and started on another one. Storing stuff as attributes in the ServletRequest object was always a better idea.

Now you've simply got another reason to do it the "right" way.

Has anybody played with any of Servlet 3 implementations and tried using ThreadLocals to prove the above?

That's not the right approach. It only tells you about the particular behaviour of a particular implementation under the particular circumstances of your test. You cannot generalize.

The correct approach is to assume that it will sometimes happen if the spec says it can ... and design your webapp to take account of it.

(Fear not! Apparently, in this case, this does not happen by default. Your webapp has to explicitly enable the async processing feature. If your code is infested with thread locals, you would be advised not to do this ...)

Apart from storing data inside HTTP Session, are there any other similar easy-to-reach hacks you could possibly advise.

Nope. The only right answer is storing request-specific data in the ServletRequest or ServletResponse object. Even storing it in the HTTP Session can be wrong, since there can be multiple requests active at the same time for a given session.

NOTE: Hacks follow. Use with caution, or really just don't use.

So long as you continue to understand which thread your code is executing in, there's no reason you can't use a ThreadLocal safely.

try {    tl.set(value);    doStuffUsingThreadLocal();} finally {    tl.remove();}

It's not as if your call stack is switched out randomly. Heck, if there are ThreadLocal values you want to set deep in the call stack and then use further out, you can hack that too:

public class Nasty {    static ThreadLocal<Set<ThreadLocal<?>>> cleanMe =         new ThreadLocal<Set<ThreadLocal<?>>>() {            protected Set<ThreadLocal<?>> initialValue() {                return new HashSet<ThreadLocal<?>>();            }        };    static void register(ThreadLocal<?> toClean) {       cleanMe.get().add(toClean);    }    static void cleanup()  {        for(ThreadLocal<?> tl : toClean)            tl.remove();        toClean.clear();    }}

Then you register your ThreadLocals as you set them, and cleanup in a finally clause somewhere. This is all shameful wankery that you shouldn't probably do. I'm sorry I wrote it but it's too late :/