Understanding Spring Transaction Propagation Mechanisms
This article explains Spring's seven transaction propagation behaviors—REQUIRED, SUPPORTS, MANDATORY, REQUIRES_NEW, NOT_SUPPORTED, NEVER, and NESTED—detailing how nested transactional methods interact, when new transactions are created or suspended, and how exceptions influence commit and rollback across different propagation settings.
Spring transaction propagation defines how transactional contexts are transferred when multiple transactional methods call each other. When a method with a transaction invokes another transactional method, the propagation setting determines whether the called method joins the existing transaction, starts a new one, or executes without a transaction.
The framework defines seven propagation types:
PROPAGATION_REQUIRED
PROPAGATION_SUPPORTS
PROPAGATION_MANDATORY
PROPAGATION_REQUIRES_NEW
PROPAGATION_NOT_SUPPORTED
PROPAGATION_NEVER
PROPAGATION_NESTED
1. REQUIRED – The default. If a transaction already exists, the method joins it; otherwise a new transaction is started.
2. SUPPORTS – Joins an existing transaction if present; if not, executes non‑transactionally.
3. MANDATORY – Must run inside a transaction; otherwise an exception is thrown.
4. REQUIRES_NEW – Always starts a new transaction, suspending any existing one.
5. NOT_SUPPORTED – Executes without a transaction, suspending any existing transaction.
6. NEVER – Must not run inside a transaction; an exception is thrown if a transaction is present.
7. NESTED – Executes within a savepoint of the existing transaction; the nested transaction can roll back independently while the outer transaction may still commit.
Examples illustrate how each propagation behaves in practice. For REQUIRED, both outer and inner methods share the same transaction, so an exception in the inner method causes a global rollback. With REQUIRES_NEW, the inner method runs in its own transaction; its rollback does not affect the outer transaction if the exception is caught. SUPPORTS and NOT_SUPPORTED show how methods may execute non‑transactionally when no outer transaction exists or when the outer transaction is deliberately suspended.
Special cases such as NEVER and MANDATORY demonstrate how Spring enforces the presence or absence of a transaction, throwing exceptions when the required condition is not met.
The article concludes that understanding these propagation rules is essential for building reliable, high‑performance enterprise applications, as the correct choice of propagation level ensures proper transaction boundaries, atomicity, and error handling.
High Availability Architecture
Official account for High Availability Architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.