asmhatre
5e9e7f1b12
Moves the existing virtual-thread/context-propagation project into context-propagation/ and adds method-security/ for the Spring Security 7 method-security article: nine runnable demos, fourteen assertions, and every transcript the article quotes, regenerated by scripts/run-all.sh. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RSrsDSRKVsY588yFiMJMo9
40 lines
2.4 KiB
Markdown
40 lines
2.4 KiB
Markdown
# 1. Why InheritableThreadLocal behaves differently with virtual threads
|
|
|
|
[Next: Async + virtual threads →](02-async-virtual-threads.md)
|
|
|
|
`Demo1PlainThreadLocal.java` has no Spring in it at all. It exists to settle one question
|
|
before Spring Security enters the picture: does `InheritableThreadLocal` actually behave
|
|
differently once the thread on the other end is virtual?
|
|
|
|
## The three cases
|
|
|
|
Every `Thread` copies the creating thread's `InheritableThreadLocal` values **once, at
|
|
construction time**. That single sentence explains everything Spring Security's concurrency
|
|
support has ever had to work around:
|
|
|
|
- A **fresh platform `Thread`** picks up whatever was set on the thread that created it. Fine.
|
|
- A **pooled platform thread** was constructed once, long ago, by the pool's internal thread
|
|
factory. Every task submitted to it later runs on that same physical thread, so it keeps
|
|
whatever `InheritableThreadLocal` value existed *when the pool created the worker*, not
|
|
what the submitting thread had at submission time. `docs/output/demo1.txt` shows this
|
|
directly: task 2 on a reused pool worker still reports `request-B`, not `request-C`, even
|
|
though the caller updated the value in between.
|
|
- A **virtual thread** is, in this respect, identical to the fresh-platform-thread case.
|
|
`Executors.newVirtualThreadPerTaskExecutor()` and `Thread.ofVirtual().start(...)` both
|
|
construct a brand new `Thread` object per task -- virtual threads are never pooled or
|
|
reused the way platform worker threads are. So the "stale value from a reused thread"
|
|
failure mode that made `SecurityContextHolder.MODE_INHERITABLETHREADLOCAL` dangerous with
|
|
`ThreadPoolTaskExecutor` simply does not exist for virtual threads.
|
|
|
|
## Why this matters for the rest of the repo
|
|
|
|
Spring Security's docs (and the original version of the blog post this repo supports) warn
|
|
against `MODE_INHERITABLETHREADLOCAL` because of the pooled-thread case above. That warning
|
|
is correct for `ThreadPoolTaskExecutor`. It stops being the relevant risk once
|
|
`spring.threads.virtual.enabled=true` swaps the executor for a `SimpleAsyncTaskExecutor`
|
|
backed by virtual threads -- there is no pool left to go stale. [Chapter 2](02-async-virtual-threads.md)
|
|
verifies that directly against `SecurityContextHolder`.
|
|
|
|
Run it yourself: `scripts/run-all.sh`, or just `demo1` from the output already captured in
|
|
[`docs/output/demo1.txt`](output/demo1.txt).
|