Transaction Management with @Transactional

Many operations need to succeed or fail as a single unit — transferring money between two accounts, for example, must either update both balances or update neither. Spring's declarative transaction management lets you express this requirement with a single annotation, @Transactional, instead of manually managing commit and rollback calls around your database code.

Under the hood, Spring wraps an annotated method (or every method of an annotated class) in a proxy that starts a transaction before the method runs, commits it if the method completes normally, and rolls it back if the method throws a runtime exception. This declarative approach keeps transaction boundaries visible and consistent without scattering try-catch-rollback logic throughout the codebase.

How @Transactional Works

Placing @Transactional on a method (most commonly a service-layer method that calls one or more repository methods) tells Spring's proxy to begin a transaction just before the method executes, and to commit that transaction once the method returns successfully. If the method throws an unchecked (RuntimeException or Error) exception, the proxy rolls the transaction back automatically. By default, checked exceptions do NOT trigger a rollback unless explicitly configured to.

Propagation Basics

Propagation controls how a transactional method behaves when it is called from within another method that is already running inside a transaction.

• REQUIRED (default) — joins the existing transaction if one is active, or starts a new one if not.
• REQUIRES_NEW — always suspends any existing transaction and starts a brand-new, independent one.
• SUPPORTS — joins an existing transaction if present, but runs non-transactionally if none exists.
• MANDATORY — requires an existing transaction to already be active, and throws an exception if none is found.

Controlling Rollback Behavior

The default rollback rule (unchecked exceptions trigger rollback, checked exceptions do not) can be overridden with rollbackFor and noRollbackFor attributes on @Transactional, e.g. @Transactional(rollbackFor = Exception.class) to force a rollback even for checked exceptions. Other useful attributes include readOnly = true, which hints to the underlying persistence provider that no writes will occur (enabling potential optimizations), and timeout, which aborts the transaction if it runs too long.

Example

import org.springframework.stereotype.Repository;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Repository
class AccountRepository {
    void debit(String accountId, double amount) {
        System.out.println("Debited " + amount + " from " + accountId);
    }
    void credit(String accountId, double amount) {
        System.out.println("Credited " + amount + " to " + accountId);
        if (accountId.equals("ACC-BAD")) {
            throw new RuntimeException("Account frozen, cannot credit");
        }
    }
}

@Service
class TransferService {
    private final AccountRepository accountRepository;
    TransferService(AccountRepository accountRepository) { this.accountRepository = accountRepository; }

    @Transactional
    public void transfer(String fromAccount, String toAccount, double amount) {
        accountRepository.debit(fromAccount, amount);
        accountRepository.credit(toAccount, amount); // throws for ACC-BAD
        // If credit() throws, Spring's proxy rolls back the whole transaction,
        // so the debit() above is also undone at the database level.
    }
}
// transferService.transfer("ACC-100", "ACC-BAD", 500.0)

Debited 500.0 from ACC-100
Credited 500.0 to ACC-BAD
RuntimeException: Account frozen, cannot credit
(Transaction rolled back — the debit from ACC-100 is undone in the database)

Exercise

Using the lesson's A money-transfer method that rolls back both updates if either fails example, create a small implementation or design sketch that demonstrates @Transactional wraps a method in a proxy that begins a transaction before it runs and commits or rolls back based on the outcome.. Add a test case or scenario that would catch Assuming @Transactional rolls back on any exception — by default only unchecked exceptions (RuntimeException/Error) trigger rollback; checked exceptions require rollbackFor to be set explicitly., and describe the expected result.

Quick quiz

Interview questions