Per-Thread Driver Holders

## What a thread-local holder actually stores A `ThreadLocal<WebDriver>` is **not** a container of drivers. It is a **key**. Every Java `Thread` object carries a small map of its own, and the `ThreadLocal` instance is the key you look up in whichever thread happens to be running. The field is `static`, so every part of a job-application-tracker suite reaches the same holder — setup, the helper that fills the *Add application* form, teardown — yet `HOLDER.get()` on the thread running *archive a rejected application* can never hand back the driver of the thread running *filter the board by status*. Three consequences follow straight from that shape: - **No locking is needed.** The map belongs to the thread reading it, so two threads never contend for one entry. - **Nothing is copied or pooled.** `set()` stores the exact reference you give it; the holder creates no drivers of its own. - **The entry's lifetime is the thread's, not the test's.** It is cleared when the thread dies, when something calls `set()` again on that thread, or when something calls `remove()` — and by nothing else. ## The three call sites A correct holder is touched in exactly three places, and they line up with the run of one case: 1. **Setup calls `set()`** with a freshly created driver, `HOLDER.set(new ChromeDriver())`. This is the only place a session is created. 2. **Helpers call `get()`** — the page code that drags an application from *Applied* to *Interviewing*, the assertion that reads the tracker's per-status counts, a listener that captures evidence on failure. 3. **Teardown calls `quit()` and then `remove()`** — first the command that ends the browser session, then the call that clears this thread's entry. Skipping the second half of step 3 is the point of the question, and it is worth asking because skipping it is invisible in a serial run. ## Why remove() is not optional on a pooled thread Test runners typically do not spawn a fresh thread per case; they hand cases to a **pool of reused worker threads**. A pooled thread does not die when a case ends, so its thread-local map does not die either. The entry your setup wrote is still sitting on that thread when the pool gives it the next case. What happens then depends on what the next case does first. If its setup calls `set()`, the old value is overwritten — the driver it pointed at becomes unreachable, and if nobody quit it, its browser is now an orphan process. If anything calls `get()` **before** that `set()` — a suite fixture, an early helper, a listener — it receives the previous case's driver. There is a quieter cost too. The entry holds a **strong reference** to the `WebDriver` value. The key is held weakly, but a `static final` holder is never collected, so the value stays reachable from a live pool thread for as long as the pool lives. Garbage collection will not rescue you, which is why an explicit `remove()` exists at all. ## quit() and remove() clean up two different things The two calls sit next to each other and are constantly confused, but they act on opposite sides of the wire — one on the browser, one on the thread. | Teardown performs | Browser session | Thread's entry | What the suite sees | |---|---|---|---| | `quit()` and `remove()` | ended | cleared | nothing; the thread is clean | | `quit()` only | ended | stale, points at a dead driver | the next `get()` on that thread returns a driver whose first command throws `NoSuchSessionException` | | `remove()` only | still running | cleared | an orphan browser process per case, until the host runs out of memory | | neither | still running | stale, points at a live driver | the next case silently drives the previous case's browser | `WebDriver.quit()` ends the session and closes every window it owns. `WebDriver.close()` closes only the current window, which is why substituting it produces the third row. `NoSuchSessionException` is documented as the exception thrown by any command issued after `quit()`: the remote end answers with the W3C `invalid session id` error, which the Java binding maps to that type. ## Ordering, and the failure that eats the clear Write the pair so the clear cannot be skipped: ```java try { driver.quit(); } finally { HOLDER.remove(); } ``` If `quit()` throws — an unreachable browser, a session the remote end already reclaimed — two plain statements in sequence never reach the second, and you land back in row two of the table. The `finally` is not defensive decoration; it is the difference between a leak that happens sometimes and one that cannot happen. ## The same shape in the other bindings Only the spelling is Java-specific. Python's `threading.local()` gives each thread its own attribute namespace on one shared object, and the equivalent of `remove()` is deleting the attribute rather than calling a method. .NET's `ThreadLocal<T>` exposes the per-thread value through its `Value` property, and the holder itself is disposable. The invariant is identical: **whatever set the value owns clearing it, because the thread underneath outlives the test that borrowed it.** Java also ships `ThreadGuard.protect(WebDriver)`, which wraps a driver so a call from a thread other than the one that constructed it throws a `WebDriverException`. It is a detector, not a holder — Selenium's documentation states plainly that it does not replace the need for a `ThreadLocal` when running in parallel.