@Transactional — Propagation Types
Fast recall
Quick revision
Core answer
Ability to reason about transaction boundaries and choose the right propagation for audit logs, batch jobs, or compensating transactions.
Using REQUIRED everywhere without understanding that an exception in a nested REQUIRED call will roll back the entire outer transaction.
Explain NESTED (uses a savepoint so the inner work can be rolled back independently while the outer transaction commits) and contrast it with REQUIRES_NEW (fully separate transaction, separate connection).
Interview-ready guide
Interview answer
@Transactional propagation controls what happens to the transaction context when one transactional method calls another. Getting it wrong produces data-consistency bugs — audit logs that vanish, operations that should be independent sharing a rollback boundary.
`REQUIRED` (the default)
- Joins the existing transaction if one is active; creates a new one if not
- Inner and outer method share the same physical transaction — an exception anywhere rolls back everything
- The audit log trap: write an audit log inside a
REQUIREDcall and the outer transaction fails — the audit log disappears with it
`REQUIRES_NEW`
- Always creates a new, independent transaction, suspending the outer one
- Uses a separate database connection — the inner commit is permanent even if the outer transaction later rolls back
- The right choice for audit logging and notifications that must persist regardless of the business outcome
- The cost: two open connections simultaneously; under high load with many
REQUIRES_NEWcalls per request, connection pool exhaustion becomes the failure mode
`NESTED`
- Creates a savepoint within the same physical connection
- Inner failure rolls back to the savepoint; the outer transaction can catch the exception and continue
- Outer failure rolls back everything — all work on the same connection
- Lower resource cost than
REQUIRES_NEWbut requires JDBC savepoint support
Regardless of propagation type: calling a @Transactional method via this bypasses the proxy — no transaction management at all. The propagation setting has no effect on self-invocation.
@Transactional — Propagation Types
Direct Answer
@Transactional propagation controls how a method behaves when a transaction already exists. REQUIRED (the default) joins an existing transaction or creates one — failure rolls back the entire outer transaction. REQUIRES_NEW suspends the existing transaction and creates an independent one on a separate connection — use it for audit logs and notifications that must persist regardless of business outcome. NESTED uses a savepoint within the same connection — inner failure can be caught while outer continues. MANDATORY, NEVER, NOT_SUPPORTED, and SUPPORTS cover specialized scenarios where you want to assert or change the transactional context without creating a new one.
Common Mistakes & Pitfalls
Using REQUIRED everywhere without understanding that an exception in a nested REQUIRED call will roll back the entire outer transaction.
Check your understanding
Answer these without looking back at the article.
- What is the difference between REQUIRES_NEW and NESTED in terms of database connections and savepoints?
- If an exception bubbles out of a REQUIRED method into its caller's transaction, what happens?
- Can you use @Transactional on private methods? Why or why not?
- How does @Transactional rollback behavior differ between checked and unchecked exceptions?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.