How do you handle transaction propagation in Spring?

Table of Contents

• Introduction
• What is Transaction Propagation?
  • Propagation Levels in Spring
  • 1. **REQUIRED** (default)
    • Example: REQUIRED
  • 2. **REQUIRES_NEW**
    • Example: REQUIRES_NEW
  • 3. **NESTED**
    • Example: NESTED
  • 4. **SUPPORTS**
    • Example: SUPPORTS
  • 5. **MANDATORY**
    • Example: MANDATORY
  • 6. **NEVER**
    • Example: NEVER
  • 7. **NOT_SUPPORTED**
    • Example: NOT_SUPPORTED
• Conclusion

Introduction

Transaction propagation in Spring refers to the way transactions are managed when multiple transactional methods are called within a single operation. The concept is essential in scenarios where one transaction depends on the outcome of other transactions. Spring provides a flexible mechanism to define how transactions should behave when one transactional method is invoked from another. This is achieved through the @Transactional annotation and its propagation attribute, which controls how Spring handles the propagation of transactions.

This guide explains how to handle transaction propagation in Spring, covering the various propagation levels and how they influence transaction behavior.

What is Transaction Propagation?

Transaction propagation defines how transactions are handled when one transaction is invoked within another transaction. Spring provides several propagation levels, each specifying how the transaction should behave in different scenarios. Propagation settings are defined using the propagation attribute of the @Transactional annotation.

Propagation Levels in Spring

Spring supports the following seven propagation behaviors for transactions:

1. **REQUIRED** (default)
2. **REQUIRES_NEW**
3. **NESTED**
4. **SUPPORTS**
5. **MANDATORY**
6. **NEVER**
7. **NOT_SUPPORTED**

1. **REQUIRED** (default)

The REQUIRED propagation level is the default behavior for Spring transactions. If a transaction already exists, the current method will participate in the existing transaction. If there is no active transaction, a new one will be created.

Example: REQUIRED

• Behavior: If the calling method is already inside a transaction, this method will participate in that transaction. If no transaction exists, a new transaction will be started.
• Common Use Case: Most of the time, REQUIRED is used because it ensures that business methods participate in a single transaction without needing explicit control over transaction boundaries.

2. **REQUIRES_NEW**

The REQUIRES_NEW propagation level always starts a new transaction, suspending any existing transaction. This means that the current method will execute in its own transaction, and any existing transaction is paused until the new one completes.

Example: REQUIRES_NEW

• Behavior: Even if there is an active transaction, a new transaction is started, and the previous one is suspended. The new transaction is committed or rolled back independently of the outer transaction.
• Common Use Case: This is useful when you need to ensure that certain actions (such as logging or auditing) happen in their own transaction, independent of the main transaction. It is also used when you want to ensure certain operations are executed even if the outer transaction fails.

3. **NESTED**

The NESTED propagation level allows a new transaction to be started, but it works like a "sub-transaction" within the parent transaction. The nested transaction can be rolled back independently of the parent, but if the parent transaction is rolled back, the nested transaction is also rolled back.

Example: NESTED

• Behavior: A nested transaction is created, which means the changes are committed or rolled back as a part of the outer transaction. However, the nested transaction can also be rolled back independently if needed (e.g., using savepoint).
• Common Use Case: NESTED is useful when you want to ensure that specific changes are isolated from the rest of the transaction, but still, they are committed or rolled back with the outer transaction unless explicitly rolled back.

4. **SUPPORTS**

The SUPPORTS propagation level means that if there is an existing transaction, the current method will participate in that transaction. If no transaction exists, the method will run without any transaction.

Example: SUPPORTS

• Behavior: If a transaction is present, the method will participate in it. If no transaction exists, the method will execute without a transaction, which is useful for read-only operations or operations that don't need transaction management.
• Common Use Case: SUPPORTS is often used for read-only methods that can run without a transaction but can join an existing one if needed.

5. **MANDATORY**

The MANDATORY propagation level requires an existing transaction. If there is no active transaction, Spring will throw an exception (IllegalTransactionStateException).

Example: MANDATORY

• Behavior: A transaction must exist when the method is invoked. If no transaction is available, an exception is thrown, indicating that the method cannot run outside a transaction.
• Common Use Case: MANDATORY is used when certain operations need to run inside an existing transaction and should not be executed outside of one.

6. **NEVER**

The NEVER propagation level ensures that the method never runs within a transaction. If a transaction exists, an exception (IllegalTransactionStateException) is thrown.

Example: NEVER

• Behavior: The method will only execute if no transaction is present. If a transaction exists, an exception is thrown.
• Common Use Case: NEVER is typically used for methods that should not be called inside a transaction, such as operations that could interfere with the transaction's integrity or behavior.

7. **NOT_SUPPORTED**

The NOT_SUPPORTED propagation level means that if there is an existing transaction, it will be suspended for the duration of the method's execution.

Example: NOT_SUPPORTED

• Behavior: If there is an existing transaction, it will be suspended for the duration of the method. Once the method completes, the transaction will resume.
• Common Use Case: NOT_SUPPORTED is useful for methods that need to run outside of a transaction context, such as operations that don't need any transaction management or involve external systems that are not transactional.

Conclusion

Transaction propagation in Spring is a key concept when working with multiple transactional methods in an application. By understanding the various propagation levels provided by Spring, you can fine-tune how transactions are managed and control the behavior of transactions in more complex scenarios.

Here’s a quick overview of when to use each propagation level:

• **REQUIRED**: Default, used when you want methods to participate in a transaction.
• **REQUIRES_NEW**: Used for methods that must run in their own independent transaction.
• **NESTED**: For methods that need a nested transaction within an outer one.
• **SUPPORTS**: For methods that should participate in an existing transaction or run without one.
• **MANDATORY**: Ensures that a method only runs within an existing transaction.
• **NEVER**: Ensures that the method never runs within a transaction.
• **NOT_SUPPORTED**: Suspends any existing transaction and runs without one.

By configuring these propagation levels appropriately, you can manage transactions effectively and control how Spring handles nested or parallel transactional behavior in your application.