What happens if you perform JPA/JDBC writes inside an afterCommit callback? Why do people say afterCommit runs 'outside' the transaction, and how do you write to the DB safely there?

## Why 'outside the transaction' A Spring transaction binds resources to the thread via `TransactionSynchronizationManager` — for JPA the `EntityManager` (through `EntityManagerHolder`), for plain JDBC the `Connection` (through `ConnectionHolder`). The commit sequence in `AbstractPlatformTransactionManager` is roughly: `triggerBeforeCommit` → `triggerBeforeCompletion` → `doCommit` → `triggerAfterCommit` → `triggerAfterCompletion` → **cleanup/unbind resources**. By the time `afterCommit` runs, the original transaction has *already committed*. The bound resource is on its way out; the logical unit of work is over. ## What actually happens if you write there Behavior varies by resource and exact timing, none of it good: - **JPA via a repository**: the original persistence context has been flushed and committed; there is no active transaction for a new write, so Spring Data / JPA may throw (no transaction) or, with an auto-commit fallback, do something you did not intend. Reads may work off a new connection; writes are unreliable. - **Plain JDBC through `DataSourceUtils.getConnection`**: you may get a fresh connection in **auto-commit** mode, so each statement commits by itself — not what a caller expecting a transaction assumes. - **Lazy-loading**: touching a lazy JPA association in afterCommit often throws `LazyInitializationException` because the persistence context is gone. The unifying point: **afterCommit is not covered by the original transaction**, so treat it as if you were outside `@Transactional` entirely. ## The safe pattern — start a new transaction Delegate the write to a *separate bean* method annotated `@Transactional(propagation = Propagation.REQUIRES_NEW)`. That opens a new physical transaction with its own connection and commits independently: ```java @Transactional(propagation = Propagation.REQUIRES_NEW) public void recordAudit(Long orderId) { auditRepo.save(new Audit(orderId)); } ``` Call it from the callback. It must be a call *through the proxy* (another bean, or self-injected proxy) — a plain `this.recordAudit(...)` self-call bypasses the proxy and gets no new transaction. ## Why REQUIRES_NEW and not REQUIRED At afterCommit time there is no active transaction to join, so `REQUIRED` would just start one anyway — but being explicit with `REQUIRES_NEW` documents intent and behaves correctly even in edge cases where synchronization state lingers. ## The inherent consistency gap The first transaction is already durable. If the new afterCommit transaction fails, you have a committed order but no audit row (or no published message). This is a genuine dual-write problem. Mitigations: - **Idempotency + retry** on the second operation. - **Transactional outbox**: within the original transaction, insert an outbox row; a separate poller publishes it — turning the second step into something recoverable. - Accept eventual consistency and monitor. ## Relationship to @TransactionalEventListener `@TransactionalEventListener(phase = AFTER_COMMIT)` handlers run at exactly this point, so the same rule applies: if the handler must persist, annotate it (or the method it calls) with `@Transactional(propagation = REQUIRES_NEW)`. There is even a documented nuance: a handler that itself opens a new transaction is fine; relying on the original context is not. ## When you do NOT need a new transaction If afterCommit only does non-DB work (send an email, publish to a broker, evict a cache, fire a metric), no transaction is needed at all — just handle failures out-of-band.