What does @Transactional do, and what happens around a method annotated with it?
answer
- proxy wraps bean, TransactionInterceptor
- begin -> run -> commit / rollback
- rollback on unchecked only, not checked
- class-level default, method-level overrides
- declarative, no manual begin/commit
basics
~10 s@Transactional tells Spring to run the method inside a database transaction: Spring starts a transaction before the method, commits if it returns normally, and rolls back if it throws a runtime exception.
solid answer
~40 s@Transactional is declarative transaction management: instead of writing begin/commit/rollback by hand, you annotate a class or method and Spring wraps it in a proxy. When a call crosses that proxy, Spring opens a transaction (or joins an existing one, per the propagation setting), runs your code, then commits on normal return. It rolls back automatically on unchecked exceptions (RuntimeException, Error) but NOT on checked exceptions unless you configure rollbackFor. It works through Spring AOP, so a TransactionInterceptor sits around the target bean and delegates the actual commit/rollback to a configured TransactionManager (e.g. JpaTransactionManager or DataSourceTransactionManager). Method-level annotations override class-level ones. You can tune propagation, isolation, readOnly, timeout, and rollback rules as attributes.
code
java · 20 lines@Service
public class TransferService {
private final AccountRepository accounts;
public TransferService(AccountRepository accounts) {
this.accounts = accounts;
}
// One atomic unit: both saves commit together, or neither does.
@Transactional
public void transfer(Long fromId, Long toId, BigDecimal amount) {
Account from = accounts.findById(fromId).orElseThrow();
Account to = accounts.findById(toId).orElseThrow();
from.debit(amount); // throws if insufficient funds -> RuntimeException -> rollback
to.credit(amount);
accounts.save(from);
accounts.save(to);
}
}go deeper
Know that it wraps the method in a DB transaction and commits/rolls back automatically.
Know the default rollback rule (unchecked only), class vs method placement, and the proxy mechanism.
Be able to name the TransactionInterceptor/TransactionManager path and reason about propagation and readOnly.
Frame it as declarative AOP-based cross-cutting concern and discuss when programmatic (TransactionTemplate) or reactive transaction management is a better fit.
## What a transaction is A database **transaction** is a unit of work that is atomic: either all its statements commit together or they are all rolled back. Without transactions, a failure halfway through a multi-step operation (e.g. debit one account, credit another) can leave data half-updated. ## Declarative vs programmatic You could manage this by hand (`connection.setAutoCommit(false)`, `commit()`, `rollback()`) — that is *programmatic* transaction management (`TransactionTemplate` is Spring's helper). `@Transactional` is *declarative*: you annotate a bean method and Spring adds the begin/commit/rollback around it for you. Less boilerplate, no transaction plumbing mixed into business logic. ## How it works mechanically `@Transactional` relies on **Spring AOP proxies**. When Spring detects transactional beans, it wraps each one in a proxy (a JDK dynamic proxy if the bean implements an interface, otherwise a CGLIB subclass proxy). The proxy holds a `TransactionInterceptor`. When an external caller invokes an annotated method: 1. The interceptor reads the method's `TransactionAttribute` (from `AnnotationTransactionAttributeSource`). 2. It asks the configured `TransactionManager` (a `PlatformTransactionManager` such as `JpaTransactionManager`, `DataSourceTransactionManager`, or `JtaTransactionManager`) to start or join a transaction per the **propagation** rule. 3. Your method body runs. 4. On normal return it commits; on a matching exception it rolls back; then it restores the previous transaction context. ## Default rollback rule (critical gotcha) Spring rolls back automatically only on **unchecked** exceptions — `RuntimeException` and `Error`. A **checked** exception (e.g. `IOException`) does NOT trigger rollback by default; the transaction commits. To change this: `@Transactional(rollbackFor = Exception.class)`. Conversely, `noRollbackFor` suppresses rollback for chosen runtime exceptions. ## Placement - On a **class**: applies to all public methods as a default. - On a **method**: overrides the class-level setting for that method. - Method-level always wins over class-level. ## Common attributes - `propagation` — REQUIRED (default: join or start), REQUIRES_NEW (suspend and start fresh), SUPPORTS, MANDATORY, NEVER, NOT_SUPPORTED, NESTED. - `isolation` — DEFAULT, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE. - `readOnly` — a hint; lets JPA/Hibernate skip dirty-checking and drivers optimize. - `timeout` — seconds before the transaction is rolled back. - `rollbackFor` / `noRollbackFor` — override the default rollback rule. ## When to use Any service method that performs multiple writes that must succeed or fail together. Put it on the **service layer**, not repositories or controllers, so one business operation equals one transaction.
- Does @Transactional roll back on a checked exception by default?No. By default Spring rolls back only on RuntimeException and Error. A checked exception commits unless you add rollbackFor = Exception.class (or a more specific checked type).
- Which layer should carry @Transactional, and why?The service layer, because a business operation (often spanning several repository calls) should be one transactional unit. Putting it on repositories fragments a single operation into many transactions.
saying these in an interview costs you the question
- Claiming @Transactional rolls back on any exception, including checked ones
- Thinking it runs the method on a background thread or asynchronously
- Saying it uses reflection to rewrite the method rather than an AOP proxy