ThreadLocal get() gives unexpected result when set() method is not invoked

Question

I have base class which contains ThreadLocal :

@Singleton
public class BaseView extends HttpServlet {

protected ThreadLocal<Locale> locale = new ThreadLocal<Locale>();

private Locale getLocale() {
    return (Locale) ObjectUtils.defaultIfNull(locale.get(), Locale.ENGLISH);
}

...

}

And it is extended in EmailValidatedView:

@Singleton
public class EmailValidatedView extends BaseView {

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    String token = req.getParameter("token");
    if (token != null) {
        try {
            User user = userService.validateEmail(token);
            locale.set(user.parseLocale());
        } catch (ServiceException e) {
            e.printStackTrace();
        }
    }
    sendResponse("validatedEmail.vm", resp.getWriter(), $());
}
}

When token is invalid, I get ServiceException and locale is not set. In this case sendResponse() method should use default locale - English. However, if I make refresh for the same page in browser with invalid token, I may get different/non related languages every time. Why does it happen?

HttpServet is annotated with @Singleton so locale should be thread safe or passed as argument in method as it mentioned http://stackoverflow.com/a/10665256/5962766 — Justinas Jakavonis, Mar 22 '16 at 07:29
When I set default locale above try-catch it solves my problem. — Justinas Jakavonis, Mar 22 '16 at 07:34
Are your classes also marked as @Singleton and ThreadLocal locale is protected which used in other extended classes? It's not my code, quite difficult to say why it was such implementation. — Justinas Jakavonis, Oct 10 '17 at 13:43

score 1 · Accepted Answer · answered Mar 22 '16 at 14:57

Most HTTP servers reuse threads from a pool. Keeping a thread-safe config is a good thing, and ThreadLocal can help, but your logic is structured such that your locale will not be reset every request. Therefore, it's unsurprising that the thread's old locales from past requests will bleed through.

You'll need to ensure your locale is set every single request that reads it, and that the default locale is set (or equivalently that the ThreadLocal value is cleared) for every new request.

ThreadLocal get() gives unexpected result when set() method is not invoked

1 Answers1