You add REQUIRES_NEW to an audit method called deep inside high-throughput request transactions. What production risks must you evaluate, and how would you mitigate them?

## The core risk: doubled connection demand + pool deadlock With REQUIRES_NEW nested inside an outer transaction, the outer connection is **suspended but still checked out** while a **second** connection is acquired for the inner tx. So a single request stack can hold **two** connections simultaneously. **Deadlock scenario:** pool size = N. N concurrent requests each begin their outer transaction and hold one connection. Each then reaches the REQUIRES_NEW audit call and requests a second connection — but the pool is empty, and no request will release its outer connection until *after* its inner call returns. Every thread blocks forever (until `connectionTimeout` fires, turning it into a storm of failures). This is a classic, well-known Hikari/pool exhaustion pattern. ### Mitigations for the pool 1. **Size the pool for peak nesting.** Effective need ≈ (max simultaneous requests in this path) × (max REQUIRES_NEW depth + 1). Or cap request concurrency (thread pool / semaphore) below `poolSize / (depth+1)`. 2. **Keep the inner transaction minimal.** A single `INSERT` with no network I/O returns its connection in milliseconds, shrinking the window where two are held. 3. **Reconsider synchronicity.** If the audit doesn't need to be written *before the request continues*, publish a Spring `ApplicationEvent` and handle it with `@TransactionalEventListener(phase = AFTER_COMPLETION)` or an async worker — the audit write then happens on its own thread/connection outside the request's critical section. Better still, a **transactional outbox**: write the audit row in the *same* outer transaction into an outbox table, and a separate poller ships it — no second connection, and the write is atomic with the business data (though it then shares the outer's commit/rollback, which may or may not be what you want). 4. **Separate DataSource/pool** for audit writes so audit connection demand can't starve the business pool (adds complexity). ## Second risk: lock & visibility surprises Because the inner tx runs on a **different connection**, it: - **Cannot see** the outer transaction's uncommitted rows (different connection, normal isolation), so audit logic that reads 'current' business rows may see stale/absent data. - **Can block on locks** the outer tx holds. If the outer transaction has locked a row that the inner audit tries to update, the inner waits — and since the outer won't proceed until the inner returns, you get a **real database deadlock** (distinct from pool deadlock). Keep the inner tx touching *disjoint* tables (a dedicated audit table) to avoid this. ## Third risk: masked failures / semantics - The whole point (survives outer rollback) also means an audit row can exist for a business action that **never committed** — downstream consumers of the audit log must tolerate 'attempted but rolled back' entries. - Exceptions from the inner tx (e.g. its own constraint violation) will propagate into the outer method unless caught; an audit failure could then roll back the business transaction — usually the opposite of intent. Wrap the audit call so its failure is logged but swallowed, if audit is best-effort. ## Observability & validation - Monitor pool metrics: `hikaricp_connections_pending`, acquire/wait time, `connectionTimeout` counts, active vs idle. - Load-test at realistic concurrency *and* nesting depth — the deadlock only appears near saturation. - Add tracing to confirm two connections are actually taken and how long the inner tx holds one. ## Decision framework - Need durability independent of the caller **and** synchronous **and** low volume → REQUIRES_NEW is fine; size the pool. - High throughput / hot path → prefer async event listener or outbox to avoid the second-connection-in-line. - Must be atomic *with* the business tx → don't use REQUIRES_NEW at all; write in the same transaction (or outbox).