How do you handle database transactions and concurrency in a Spring Boot application?

Managing database transactions and concurrency is crucial for building robust and reliable Spring Boot applications. Spring provides powerful abstractions to simplify transaction management and offers various strategies to handle concurrent data access, ensuring data integrity and consistency.

Transaction Management in Spring Boot

Spring Boot leverages Spring Framework's comprehensive transaction management capabilities, primarily through declarative transaction management using the @Transactional annotation. This approach allows developers to define transactional boundaries at the method or class level without writing boilerplate transaction management code.

@Service
public class AccountService {

    @Autowired
    private AccountRepository accountRepository;

    @Transactional
    public void transferFunds(Long fromAccountId, Long toAccountId, double amount) {
        Account fromAccount = accountRepository.findById(fromAccountId)
                               .orElseThrow(() -> new RuntimeException("Account not found"));
        Account toAccount = accountRepository.findById(toAccountId)
                             .orElseThrow(() -> new RuntimeException("Account not found"));

        if (fromAccount.getBalance() < amount) {
            throw new InsufficientFundsException("Insufficient funds in account " + fromAccountId);
        }

        fromAccount.setBalance(fromAccount.getBalance() - amount);
        toAccount.setBalance(toAccount.getBalance() + amount);

        accountRepository.save(fromAccount);
        accountRepository.save(toAccount);
    }

    @Transactional(readOnly = true)
    public Account getAccountDetails(Long accountId) {
        return accountRepository.findById(accountId).orElse(null);
    }
}

When @Transactional is applied to a method, Spring creates a proxy that wraps the method execution in a database transaction. If the method completes successfully, the transaction commits; if an unchecked exception is thrown, the transaction rolls back. Key properties of @Transactional include propagation (e.g., REQUIRED, REQUIRES_NEW), isolation (e.g., READ_COMMITTED, REPEATABLE_READ), readOnly (for optimization), and rollbackFor/noRollbackFor (to define custom exception handling for rollback).

Programmatic Transaction Management

While declarative transactions are preferred for most use cases due to their simplicity, programmatic transaction management offers finer-grained control. This can be achieved using PlatformTransactionManager directly or via TransactionTemplate.

@Service
public class UserService {

    @Autowired
    private PlatformTransactionManager transactionManager;

    public void createUserProgrammatically(User user) {
        TransactionTemplate transactionTemplate = new TransactionTemplate(transactionManager);
        transactionTemplate.execute(status -> {
            // Perform database operations
            // e.g., userRepository.save(user);
            // If an exception occurs, transaction will rollback
            return null;
        });
    }
}

Handling Concurrency Issues

Concurrency issues arise when multiple transactions attempt to access and modify the same data simultaneously. Common problems include dirty reads, non-repeatable reads, and phantom reads. While transaction isolation levels help mitigate these, more specific strategies like optimistic and pessimistic locking are often required for robust data integrity.

Optimistic Locking

Optimistic locking is a non-blocking approach where transactions proceed without acquiring explicit database locks. It relies on a version column (typically an integer or timestamp) in the database table. When a record is updated, its version is checked; if it doesn't match the version read initially, it indicates that another transaction modified the data, leading to an OptimisticLockingFailureException. This approach is generally preferred for its better performance and scalability.

@Entity
public class Product {
    @Id
    private Long id;
    private String name;
    private double price;

    @Version
    private int version; // This field is crucial for optimistic locking

    // Getters and Setters
}

Spring Data JPA automatically handles the version checking and incrementing when @Version is present on an entity. This strategy is efficient as it avoids database-level locks, making it suitable for applications with high concurrency and relatively low contention.

Pessimistic Locking

Pessimistic locking involves acquiring explicit locks on database rows or tables to prevent other transactions from accessing or modifying the data until the lock is released. This ensures exclusive access but can reduce concurrency and potentially lead to deadlocks if not managed carefully. It's suitable for scenarios with high contention where preventing concurrent modifications is paramount.

public interface ProductRepository extends JpaRepository<Product, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT p FROM Product p WHERE p.id = :id")
    Optional<Product> findByIdWithPessimisticLock(Long id);

    // Alternatively, you can override a standard method:
    // @Lock(LockModeType.PESSIMISTIC_WRITE)
    // Optional<Product> findById(Long id);
}

Spring Data JPA allows applying pessimistic locks using the @Lock annotation with LockModeType.PESSIMISTIC_READ (allows other transactions to read but not write) or LockModeType.PESSIMISTIC_WRITE (prevents both reads and writes). This is often implemented using SELECT FOR UPDATE at the database level.

Best Practices

• Keep transactions as short as possible to minimize resource locking and contention.
• Choose appropriate isolation levels based on application requirements; READ_COMMITTED is common for most web apps, while REPEATABLE_READ offers stricter consistency.
• Prefer optimistic locking (@Version) for general-purpose concurrency control due to its scalability and performance benefits.
• Use pessimistic locking (@Lock) sparingly and only when absolute data integrity is required over concurrent access for specific critical operations (e.g., inventory management).
• Thoroughly test concurrent scenarios to identify and resolve potential issues like deadlocks or race conditions.
• Understand the default transaction behavior of your chosen persistence framework (e.g., JPA/Hibernate) and underlying database.