Why might a @Transactional(timeout = ...) value appear to be ignored at runtime? Cover propagation and what the timeout does and doesn't bound.

## Reason 1: propagation — the timeout binds to a *new* transaction only Spring assigns a timeout deadline only in `doBegin`, i.e. when it **physically starts** a transaction. Consider: ```java @Transactional(timeout = 30) public void outer() { inner(); } @Transactional(timeout = 2) // PROPAGATION_REQUIRED (default) public void inner() { ... } ``` `inner()` **joins** `outer()`'s transaction rather than starting a new one, so its `timeout = 2` is **not applied**. The already-running transaction keeps its 30-second deadline. By default `AbstractPlatformTransactionManager.validateExistingTransaction` is `false`, so Spring **silently ignores** the mismatch. If you set that flag to `true`, Spring instead **throws** `IllegalTransactionStateException` complaining the participating definition's timeout differs from the existing one. Either way, the inner value never quietly 'wins.' To make a tighter timeout actually take effect on a nested call, use `@Transactional(propagation = Propagation.REQUIRES_NEW, timeout = 2)` — that **suspends** the outer transaction and begins a new one with its own 2-second deadline. Also note: self-invocation (a method in the same bean calling another `@Transactional` method via `this`) bypasses the proxy entirely, so the second annotation — including its timeout — is ignored. That's a separate but commonly-conflated reason a timeout 'does nothing.' ## Reason 2: it bounds DB work, checked at statement boundaries The timeout is enforced by (a) `Statement.setQueryTimeout(remaining)` on each JDBC statement and (b) a deadline check via `getTimeToLiveInSeconds()` before Spring hands out that remaining time. Implications: - A **single long query** is cancelled by the database (query timeout). - **Non-DB work between queries** — a busy loop, `Thread.sleep`, a slow REST call — is **not interrupted** while it runs. The overshoot is only detected when the *next* database statement runs and finds the deadline passed, at which point `TransactionTimedOutException` is thrown. So a method that does one query then computes for 10 minutes with `timeout = 5` will not be aborted at 5s; it finishes the CPU work and only fails if it touches the DB again. - If the **driver ignores `setQueryTimeout`** (not all do, and behavior varies), even in-flight queries won't be cancelled and you rely solely on the boundary check. ## Reason 3: value validity / not being in a transaction at all - If the method isn't actually transactional (proxy not applied, `@Transactional` on a non-public method with the default proxy config, or self-invocation), the timeout is irrelevant. - Some transaction managers (`JtaTransactionManager` in certain setups) may not support a per-transaction timeout the same way; the value can be delegated to the JTA provider (`UserTransaction.setTransactionTimeout`). ## Practical guidance - Put the timeout on the **outermost** transactional boundary that owns the physical transaction, or use `REQUIRES_NEW` when a nested unit genuinely needs its own budget. - Don't expect a timeout to protect against slow **non-database** operations — keep external calls out of transactions, or guard them with their own timeouts. - Pair the Spring timeout with DB-side `statement_timeout` / `lock_timeout` for defense in depth, since Spring's mechanism depends on driver cooperation.