Springmedium

How does `@Transactional` work (rollback + common gotcha)?

Answer

It runs the method inside a transaction; by default Spring rolls back on unchecked (`RuntimeException`) errors. A common gotcha is self-invocation: calling a `@Transactional` method from the same class bypasses the proxy, so the transaction may not start.

@Service
class PaymentService {
  @Transactional
  public void pay() {
    // DB writes here
  }
}

Advanced answer

Deep dive

In most Spring apps, `@Transactional` is implemented via an AOP **proxy**. The proxy starts a transaction before your method runs and commits/rolls back after it finishes.

Rollback rules (default)

Spring rolls back on:

`RuntimeException`
`Error`

Checked exceptions do **not** trigger rollback unless configured:

@Transactional(rollbackFor = Exception.class)

Why self-invocation is a problem

Only calls that go **through the proxy** get transactional behavior. `this.someTransactionalMethod()` stays inside the bean and bypasses the proxy.

Practical guidance

Place transaction boundaries on service-layer methods (use-case boundaries).
Don’t swallow exceptions if you want rollback.
Use propagation/isolation explicitly only when needed.

Common pitfalls

Catching exceptions and returning “success” (transaction commits).
`@Transactional` on private/final methods (proxy limitations depending on setup).
Returning lazy JPA entities outside the transaction (leads to `LazyInitializationException`).