Can @Transactional and @Async Work Together?

1. Introduction

In this article, we’ll examine the compatibility between the @Transactional and @Async annotations of the Spring framework.

2. Understanding @Transactional and @Async

The @Transactional annotation creates an atomic code block from many others. So, if one block is completed exceptionally, all the parts roll back. Hence, the newly created atomic unit is only completed successfully with a commit when all its parts are successful.

Creating transactions allows us to avoid partial failures in our code, improving data consistency.

On the other hand, @Async tells Spring that the annotated unit can run in parallel with the calling thread. In other words, if we call an @Async method or class from a thread, Spring runs its code in another thread with a different context.

Defining asynchronous code can improve execution time performance by executing units in parallel with the calling thread.

There are scenarios in which we need both performance and consistency in our code. With Spring, we can mix @Transactional and @Async to achieve those two goals, as long as we pay attention to how we use the annotations together.

In the following sections, we’ll explore different scenarios.

3. Can @Transactional and @Async Work Together?

Asynchronous and transactional code might introduce problems like data inconsistency if we don’t implement them properly.

It’s fundamental to pay attention to Spring’s transactional context and data propagation between contexts to fully take advantage of @Async and @Transactional and avoid pitfalls.

3.1. Creating the Demo Application

We’ll use the transfer functionality from a banking service to illustrate the use of transactions and asynchronous code.

In short, we can implement money transfers by removing money from one account and adding it to another. We can picture that as database operations like selecting the involved accounts and updating their money balance:

public void transfer(Long depositorId, Long favoredId, BigDecimal amount) {
    Account depositorAccount = accountRepository.findById(depositorId)
      .orElseThrow(IllegalArgumentException::new);
    Account favoredAccount = accountRepository.findById(favoredId)
      .orElseThrow(IllegalArgumentException::new);

    depositorAccount.setBalance(depositorAccount.getBalance().subtract(amount));
    favoredAccount.setBalance(favoredAccount.getBalance().add(amount));

    accountRepository.save(depositorAccount);
    accountRepository.save(favoredAccount);
}

We start by finding the involved accounts using findById() and throw an IllegalArgumentException if the given ID doesn’t find the account.

Then, we update the retrieved account with the new amount. Finally, we save the newly updated account using CrudRepository‘s save() method.

In this simple example, there are a few potential failures. For instance, we might not find the favoredAccount and fail with an exception. Or, the save() operation completes for depositorAccount but fails for favoredAccount. Those are defined as partial failures because what happened before the failure can’t be undone.

Hence, partial failures create data consistency problems if we don’t manage our code properly with transactions. For instance, we might remove money from an account without effectively passing it to another.

3.2. Calling @Transactional From @Async

If we call the @Transactional method from the @Async method, Spring correctly manages the transaction and propagates its context, ensuring data consistency.

For instance, let’s call a @Transactional transfer() method from an @Async caller:

@Async
public void transferAsync(Long depositorId, Long favoredId, BigDecimal amount) {
    transfer(depositorId, favoredId, amount);

    // other async operations, isolated from transfer
}

@Transactional
public void transfer(Long depositorId, Long favoredId, BigDecimal amount) {
    Account depositorAccount = accountRepository.findById(depositorId)
      .orElseThrow(IllegalArgumentException::new);
    Account favoredAccount = accountRepository.findById(favoredId)
      .orElseThrow(IllegalArgumentException::new);

    depositorAccount.setBalance(depositorAccount.getBalance().subtract(amount));
    favoredAccount.setBalance(favoredAccount.getBalance().add(amount));

    accountRepository.save(depositorAccount);
    accountRepository.save(favoredAccount);
}

The transferAsync() method runs in parallel with the calling thread in a different context since it’s @Async.

Then, we call the transactional transfer() method to run the crucial business logic. In that case, Spring correctly propagates the transferAsync() thread context to transfer(). Hence, we don’t lose any data in that interaction.

The transfer() method defines a set of crucial database operations that must be rolled back if something fails. Spring only handles the transfer() transaction, which isolates all code outside the transfer() body from the transaction. Therefore, Spring only rolls back the transfer() code if something fails.

Calling a @Transactional from an @Async method can be useful for improving performance by executing operations in parallel with the calling thread without having data inconsistencies in specific internal operations.

3.3. Calling @Async From @Transactional

Spring currently uses ThreadLocal to manage the current thread transaction. Hence, it doesn’t share thread contexts between different threads of our application.

Thus, if a @Transactional method calls an @Async method, Spring doesn’t propagate the same thread context of the transaction.

To illustrate, let’s add a call to the async printReceipt() method inside transfer():

@Async
public void transferAsync(Long depositorId, Long favoredId, BigDecimal amount) {
    transfer(depositorId, favoredId, amount);
}

@Transactional
public void transfer(Long depositorId, Long favoredId, BigDecimal amount) {
    Account depositorAccount = accountRepository.findById(depositorId)
      .orElseThrow(IllegalArgumentException::new);
    Account favoredAccount = accountRepository.findById(favoredId)
      .orElseThrow(IllegalArgumentException::new);

    depositorAccount.setBalance(depositorAccount.getBalance().subtract(amount));
    favoredAccount.setBalance(favoredAccount.getBalance().add(amount));

    printReceipt();
    accountRepository.save(depositorAccount);
    accountRepository.save(favoredAccount);
}

@Async public void printReceipt() { // logic to print the receipt with the results of the transfer }

The transfer() logic is the same as earlier, but now we call printReceipt() to print the transfer result. Since printReceipt() is @Async, Spring runs its code on a different thread with another context.

The problem is that the receipt information depends on correctly executing the entire transfer() method. Additionally, printReceipt() and the rest of the transfer() code that saves into the database runs on different threads with different data, making the application behavior unpredictable. For example, we may print the result of a money transfer transaction that wasn’t successfully saved into the database.

Thus, to avoid that kind of data consistency problem, we must avoid calling an @Async method from a @Transactional since thread context propagation doesn’t occur.

3.4. Using @Transactional at the Class Level

Defining a class with @Transactional makes all its public methods available for Spring transaction management. Thus, the annotation creates transactions for all methods at once.

One thing that might occur when using @Transactional at the class level is mixing it with @Async in the same method. In practice, we’re creating a transactional unit around that method that runs in a thread different from the calling thread:

@Transactional
public class AccountService {
    @Async
    public void transferAsync() {
        // this is an async and transactional method
    }

    public void transfer() {
        // transactional method
    }
}

In the example, the transferAsync() method is transactional and async. Thus, it defines a transactional unit and runs on a different thread. Hence, it’s available for transaction management but not in the same context as the calling thread.

Thus, if something fails, the code inside transferAsync() rolls back because it’s @Transactional. However, since that method is also @Async, Spring doesn’t propagate the calling context to it. Thus, in the failure scenario, Spring doesn’t roll back any code outside of trasnferAsync() like when we call a sequence of transactional-only methods. Therefore, this falls into the same data integrity problem as calling a @Async from @Transactional.

The class-level annotation is handy for writing less code to create a class that defines a sequence of fully transactional methods.

However, this mixed transactional and async behavior might create confusion when troubleshooting the code. For instance, we expect all code in a sequence of transactional-only method calls to be rollbacked when a failure occurs. However, if a method of that sequence is also @Async, the behavior is unexpected.

4. Conclusion

In this tutorial, we’ve learned when it’s safe to use @Transactional and @Async annotations together from a data integrity perspective.

In general, calling @Transactional from a @Async method guarantees data integrity since Spring properly propagates the same context.

On the other hand, when calling @Async from @Transactional, we might fall into data integrity problems.

As always, the source code is available over on GitHub.