Backend Development 10 min read

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.

High Availability Architecture
High Availability Architecture
High Availability Architecture
Understanding Spring Transaction Propagation Mechanisms

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.

backendJavatransactionSpringTransactionalPropagation
High Availability Architecture
Written by

High Availability Architecture

Official account for High Availability Architecture.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.