Transactions and Concurrency in Spring

Transactions and Concurrency in Spring

@Transactional looks like a single annotation, but it's the surface of a proxy-based mechanism with real, consequential decisions hiding underneath: propagation behavior, isolation level, read-only optimization, and rollback rules. Getting these wrong doesn't usually fail loudly — it fails as a subtle data-consistency bug that shows up under concurrent load, weeks after the code shipped. This guide covers @Transactional from the AOP mechanism up through the locking strategies you need for real concurrent write paths.

1. How @Transactional Actually Works

Spring's declarative transaction management is implemented with AOP proxies, not bytecode magic inside your class. When you annotate a @Service bean's method with @Transactional, Spring wraps the bean in a proxy at startup that begins a transaction before the method runs and commits/rolls back after it returns.

@Service
public class OrderService {
 
    @Transactional
    public void placeOrder(OrderRequest request) {
        Order order = createOrder(request);
        this.chargeCustomer(order);   // ← proxy bypassed, new @Transactional ignored!
    }
 
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void chargeCustomer(Order order) {
        // this NEVER runs in its own transaction when called via `this.`
    }
}

Default rollback rules

By default, Spring rolls back on unchecked exceptions (RuntimeException, Error) and commits on checked exceptions. This trips people up coming from a "any exception rolls back" mental model.

@Transactional(rollbackFor = OrderValidationException.class)  // checked exception — must opt in
public void placeOrder(OrderRequest request) throws OrderValidationException {
    if (!isValid(request)) {
        throw new OrderValidationException("Invalid order");  // rolled back only because of rollbackFor
    }
}

2. Propagation Types

Propagation controls how a transactional method behaves when called from within an existing transaction — join it, suspend it, nest inside it, or reject it.

REQUIRES_NEW in practice: audit logging that survives a rollback

@Service
public class OrderService {
    private final AuditLogService auditLogService;
 
    @Transactional
    public void placeOrder(OrderRequest request) {
        auditLogService.logAttempt(request);  // must survive even if placeOrder rolls back
        Order order = validateAndCreate(request);  // may throw
        orderRepository.save(order);
    }
}
 
@Service
public class AuditLogService {
 
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void logAttempt(OrderRequest request) {
        auditRepository.save(new AuditEntry(request));
        // commits independently, even if the caller's transaction later rolls back
    }
}

NESTED vs REQUIRES_NEW

3. Isolation Levels

Isolation levels control what concurrent transactions are allowed to see of each other's uncommitted or concurrently-committed changes.

@Transactional(isolation = Isolation.READ_COMMITTED)
public BigDecimal getAccountBalance(Long accountId) {
    return accountRepository.findById(accountId)
        .orElseThrow()
        .getBalance();
}

The three read anomalies

4. Read-Only Transactions

@Transactional(readOnly = true)
public List<OrderSummary> listOrders(Long customerId) {
    return orderRepository.findSummariesByCustomer(customerId);
}

readOnly = true is a hint, not an enforced constraint at the JPA level — but Hibernate uses it to:

• Set the underlying JDBC connection's read-only flag (some drivers/DBs use this to route to a read replica).
• Skip dirty checking at flush time — Hibernate won't diff entity state against its loaded snapshot, saving CPU on large result sets.
• Optionally set FlushMode.MANUAL, avoiding unnecessary flush cycles.

5. Optimistic Locking with @Version

Optimistic locking assumes conflicts are rare — it lets transactions proceed without locking rows, and detects conflicts only at commit time.

@Entity
public class Account {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "account_seq")
    private Long id;
 
    private BigDecimal balance;
 
    @Version
    private Long version;
}

Every UPDATE Hibernate issues includes the version in the WHERE clause and increments it:

UPDATE account SET balance = ?, version = version + 1
WHERE id = ? AND version = ?

If another transaction already committed a change (bumping the version), this UPDATE affects zero rows, and Hibernate throws OptimisticLockException (wrapped as ObjectOptimisticLockingFailureException by Spring).

@Service
public class AccountService {
    private final AccountRepository accountRepository;
 
    @Retryable(
        retryFor = ObjectOptimisticLockingFailureException.class,
        maxAttempts = 3,
        backoff = @Backoff(delay = 50, multiplier = 2)
    )
    @Transactional
    public void withdraw(Long accountId, BigDecimal amount) {
        Account account = accountRepository.findById(accountId).orElseThrow();
        if (account.getBalance().compareTo(amount) < 0) {
            throw new InsufficientFundsException(accountId);
        }
        account.setBalance(account.getBalance().subtract(amount));
        // no explicit save() needed — dirty checking flushes the UPDATE on commit
    }
}

6. Pessimistic Locking

Pessimistic locking acquires a database-level row lock before reading, blocking other transactions from reading (in exclusive mode) or writing to the same row until the lock is released.

public interface AccountRepository extends JpaRepository<Account, Long> {
 
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT a FROM Account a WHERE a.id = :id")
    Optional<Account> findByIdForUpdate(@Param("id") Long id);
}

Generates (on Postgres):

SELECT * FROM account WHERE id = ? FOR UPDATE;

@Service
public class AccountService {
    private final AccountRepository accountRepository;
 
    @Transactional
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        // lock ordering matters — always lock in a consistent order to avoid deadlocks
        Long first = Math.min(fromId, toId);
        Long second = Math.max(fromId, toId);
 
        Account a = accountRepository.findByIdForUpdate(first).orElseThrow();
        Account b = accountRepository.findByIdForUpdate(second).orElseThrow();
 
        Account from = fromId.equals(first) ? a : b;
        Account to = fromId.equals(first) ? b : a;
 
        from.setBalance(from.getBalance().subtract(amount));
        to.setBalance(to.getBalance().add(amount));
    }
}

7. Optimistic vs Pessimistic: Choosing

8. Production Observations

• Transaction boundaries belong at the service layer, not the repository or controller layer — one @Transactional service method per logical unit of work.
• Keep transactions short. Never call an external HTTP API, send an email, or do slow I/O inside a @Transactional method — it holds a DB connection and, under pessimistic locking, row locks, for the entire duration.
• @Transactional on a private method silently does nothing — Spring's proxy-based AOP can only intercept public method calls made through the proxy.
• Test transactional behavior explicitly. @Transactional on a @SpringBootTest rolls back after each test by default — useful for isolation, but make sure you're not accidentally testing behavior that only "works" because of that automatic rollback masking a missing @Transactional in production code.

Key takeaways

• @Transactional is implemented via AOP proxies — self-invocation (this.method()) silently bypasses it.
• By default, Spring rolls back on unchecked exceptions only; use rollbackFor to roll back on checked exceptions.
• REQUIRED (default) joins an existing transaction; REQUIRES_NEW suspends it and opens an independent one (uses a second DB connection); NESTED uses a savepoint within the same connection.
• Isolation levels trade correctness guarantees (dirty/non-repeatable/phantom reads) for concurrency; most services never need anything beyond the database's default (READ_COMMITTED on Postgres).
• Mark every read-only service method @Transactional(readOnly = true) — it's a free optimization and a documentation signal.
• Optimistic locking (@Version) scales better under normal contention; pessimistic locking (SELECT FOR UPDATE) is for genuine hotspots where retries would themselves become a bottleneck.
• Always acquire pessimistic locks in a consistent, global order to avoid deadlocks.
• Keep transactions short — no external calls, no slow I/O — since they hold DB connections and, under pessimistic locks, block other transactions.

Interview Questions

• How is @Transactional implemented under the hood in Spring? What is the practical consequence of it being proxy-based?
• Why does calling a @Transactional method via this. from within the same class not start a new transaction?
• What is the default rollback behavior in Spring — does it roll back on checked exceptions?
• Explain the difference between REQUIRED, REQUIRES_NEW, and NESTED propagation, with a concrete use case for each.
• What database resource cost does REQUIRES_NEW incur that NESTED avoids?
• What are dirty reads, non-repeatable reads, and phantom reads? Which isolation levels prevent each?
• Why is READ_COMMITTED a reasonable default for most web applications, and when would you escalate to SERIALIZABLE?
• What does @Transactional(readOnly = true) actually change about Hibernate's behavior?
• How does optimistic locking with @Version detect a conflicting concurrent update? What SQL does Hibernate generate?
• When would you choose pessimistic locking over optimistic locking?
• What causes a deadlock in a pessimistic-locking transfer operation, and how do you prevent it?
• What's the difference between PESSIMISTIC_READ and PESSIMISTIC_WRITE?
• Why should you avoid making external HTTP calls inside a @Transactional method?
• How would you design a retry strategy for ObjectOptimisticLockingFailureException?