Doc: LocaleContextHolder with inheritable only propagates to newly created threads

[heyarny]

I noticed that the Locales when trying to use them inside threads are not consistent when using LocaleContextHolder.setLocale(Locale.GERMAN, true);.
It seems like the thread pools use the language it once was sent and uses it for all other requests.
You can reporduce it when using a threadpool of 1.

This is the Test I have:

@SpringBootTest
class AsyncContextPropagationTest {

    private ThreadPoolTaskExecutor delegate;
    private TaskExecutor taskExecutor;

    @BeforeEach
    void setUpExecutor() {
        delegate = new ThreadPoolTaskExecutor();
        delegate.setCorePoolSize(1);
        delegate.setMaxPoolSize(100);
        delegate.setQueueCapacity(50);
        delegate.setThreadNamePrefix("test-async-");
        delegate.initialize();

        taskExecutor = new DelegatingSecurityContextAsyncTaskExecutor(delegate);
    }

    @AfterEach
    void tearDownExecutor() {
        if (delegate != null) {
            delegate.shutdown();
        }
    }

    @Test
    void localeIsVisibleInAsyncTask() {
        LocaleContextHolder.setLocale(Locale.GERMAN, true);
        CompletableFuture<Locale> futureGerman = CompletableFuture.supplyAsync(
            LocaleContextHolder::getLocale,
            taskExecutor
        );
        var futureGermanResult = futureGerman.join();

        LocaleContextHolder.setLocale(Locale.ENGLISH, true);
        CompletableFuture<Locale> futureEnglish = CompletableFuture.supplyAsync(
            LocaleContextHolder::getLocale,
            taskExecutor
        );

        var futureEnglishResult = futureEnglish.join();

        assertThat(futureGermanResult).isEqualTo(Locale.GERMAN);
        assertThat(futureEnglishResult).isEqualTo(Locale.ENGLISH);
    }
}

Right now the workaround is to use an explicit TaskDecorator for that case to copy the locale to all child threads.

public class ContextCopyingDecorator implements TaskDecorator {

    @NonNull
    @Override
    public Runnable decorate(@NonNull Runnable runnable) {
        var locale = LocaleContextHolder.getLocale();

        return () -> { // code runs inside executor thread and binds context
            try {
                if (locale != null) {
                    LocaleContextHolder.setLocale(locale);
                }
                runnable.run();
            } finally {
                // Nothing to do.
            }
        };
    }
}

Then set it via delegate.setTaskDecorator(new ContextCopyingDecorator()); and it works just fine.

Not sure if the inheritable on setLocale() is intended to work like that or its simply a bug.
At least I don't know why it would work like that.

[SoftDeveloperSahil]

use the resetLocalContext
Request A → GERMAN → reset
Request B → clean → sets its own locale

how to fix in code :

Locale locale = LocaleContextHolder.getLocale();

return () -> {
Locale previous = LocaleContextHolder.getLocale();
try {
LocaleContextHolder.setLocale(locale);
runnable.run();
} finally {
LocaleContextHolder.setLocale(previous);
}
};

[heyarny]

@SoftDeveloperSahil I already provided a working solution.

This issue is about the inheritable in LocaleContextHolder.setLocale(Locale .. , inheritable); which is not working as expected.

[SoftDeveloperSahil]

@heyarny thanks for the clarification, I understand your point.

[jhoeller]

I'm afraid this is by design, and not even Spring's design but rather the JDK's: java.lang.InheritableThreadLocal only inherits to newly created child threads within the given parent thread where the ThreadLocal has been set. This is fundamentally incompatible with thread pools where new threads might be created but it's much more likely that existing threads are reused which still carry the ThreadLocal state from the time of their initial creation. From that perspective, use of inheritable is strongly discouraged in practice,

The suggestion above to wrap LocaleContextHolder around every Runnable execution is the recommended solution indeed. This can also be implemented in a TaskDecorator that captures LocaleContextHolder.getLocale() from the caller thread and passes that Locale instance into a decorator Runnable that applies the given Locale around the target Runnable#execute() invocation.

Last but not least, InheritableThreadLocal and Spring's use thereof in LocaleContextHolder will actually work fine with Virtual Threads which are freshly created for every task. So there might be some new life for this flag in a Virtual Thread setup.

I'll turn this into a documentation issue since there is definitely room for additional notes there.