What is @TransactionalEventListener and what is its default phase?
answer
- specialization of @EventListener
- default = AFTER_COMMIT
- ties handler to tx lifecycle
- no tx + no fallback = skipped
- registers TransactionSynchronization
basics
~10 sIt's a Spring event listener that only fires relative to a transaction. By default it runs in the AFTER_COMMIT phase, so it executes only after the surrounding transaction successfully commits.
solid answer
~30 s@TransactionalEventListener is a specialization of @EventListener that binds the listener's execution to the lifecycle of the transaction that was active when the event was published. Instead of running synchronously at publish time (like @EventListener), it registers a transaction synchronization callback and runs at a chosen phase. The default phase is TransactionPhase.AFTER_COMMIT, meaning the handler runs only after the publishing transaction commits successfully. This is the common pattern for 'do side effects only if the data was actually persisted' — sending emails, publishing to a message broker, etc. If no transaction is active, by default the listener is silently skipped unless fallbackExecution=true.
code
java · 18 lines@Component
public class OrderNotifier {
// Default phase is AFTER_COMMIT: fires only after a successful commit
@TransactionalEventListener
public void onOrderPlaced(OrderPlacedEvent event) {
// safe to send an email — the order row is durably committed
emailService.sendConfirmation(event.orderId());
}
}
// Publisher side (inside a @Transactional method)
@Transactional
public void placeOrder(Order order) {
orderRepository.save(order);
eventPublisher.publishEvent(new OrderPlacedEvent(order.getId()));
// listener runs after this method's tx commits
}go deeper
Know it's @EventListener bound to a transaction and the default is AFTER_COMMIT.
Explain the no-transaction skip behavior and fallbackExecution.
Discuss the TransactionSynchronization mechanism and why AFTER_COMMIT is the safe default for side effects.
Frame it as a durability boundary for outbox/side-effect patterns and reason about failure modes when no tx is present.
## What it is `@TransactionalEventListener` (package `org.springframework.transaction.event`) is a specialized form of `@EventListener`. A normal `@EventListener` handles an application event **synchronously at the moment `ApplicationEventPublisher.publishEvent(...)` is called** — regardless of any transaction. `@TransactionalEventListener` instead **defers** the handler and ties it to the **current transaction's lifecycle**, so it fires at a specific point relative to commit/rollback. ## How it works under the hood When an event is published inside an active transaction, Spring registers a `TransactionSynchronization` callback (via `TransactionSynchronizationManager`). That callback fires the listener during the transaction's commit/completion sequence, at the configured `TransactionPhase`. ## The `phase` attribute (TransactionPhase enum) - `BEFORE_COMMIT` — runs just before the transaction commits (during `beforeCommit`). Still inside the transaction, so DB writes here participate in the **same** commit. - `AFTER_COMMIT` — **the default**. Runs after a successful commit. The transaction is already committed; new DB work here needs a new transaction. - `AFTER_ROLLBACK` — runs after the transaction rolls back. - `AFTER_COMPLETION` — runs after the transaction completes, **regardless** of commit or rollback outcome. (`AFTER_COMMIT` and `AFTER_ROLLBACK` are mutually exclusive refinements of `AFTER_COMPLETION`.) ## fallbackExecution By default, if there is **no active transaction** when the event is published, the listener does **not** run at all (Spring logs at trace/debug that no transaction synchronization is active). Setting `fallbackExecution = true` makes the listener run immediately, like a plain `@EventListener`, when no transaction is present. ## When to use which phase - `AFTER_COMMIT` (default): trigger external side effects only if the data was durably persisted — send emails, enqueue messages, invalidate caches. Most common. - `BEFORE_COMMIT`: do additional work that must be part of the same atomic commit (extra validation, additional persistence that should roll back together). - `AFTER_ROLLBACK`: compensation/cleanup after failure. - `AFTER_COMPLETION`: unconditional cleanup regardless of outcome. ## Key gotchas - The default `AFTER_COMMIT` handler runs **after** commit, so any JPA/DB operations you perform there are **not** part of the committed transaction. If you write to the DB in an AFTER_COMMIT handler using the same (now read-only-ish) context, it may be silently lost unless you open a **new** transaction (e.g., `@Transactional(propagation = REQUIRES_NEW)`). - Without an active transaction and without `fallbackExecution=true`, your handler **silently does nothing** — a classic 'my listener never fires' bug. - The event must be published **while a transaction is active** for the deferral to work.
- How does @TransactionalEventListener differ from @EventListener?@EventListener runs synchronously at publishEvent() time regardless of any transaction. @TransactionalEventListener defers execution and binds it to the current transaction's phase (default AFTER_COMMIT), and by default is skipped entirely if no transaction is active.
- What happens if you publish the event outside a transaction?By default the listener is not invoked at all. You must set fallbackExecution=true for it to run immediately like a normal @EventListener.
saying these in an interview costs you the question
- Thinking the default phase is BEFORE_COMMIT
- Believing the listener always runs even without a transaction
- Confusing it with @EventListener (synchronous at publish time)