@Transactional Internals — Proxy and Propagation

Direct Answer

@Transactional is implemented entirely as a Spring AOP proxy: at startup, Spring wraps every @Transactional bean in a CGLIB subclass (or JDK dynamic proxy for interface-based beans). The proxy overrides each annotated method with code that opens a transaction via PlatformTransactionManager.getTransaction(), invokes the real method, and commits on success or rolls back on RuntimeException/Error. This proxy architecture explains every @Transactional gotcha — self-invocation silently skips the transaction (calling this.method() bypasses the proxy entirely), annotations on private/final/static methods are ignored, and only unchecked exceptions trigger rollback by default. Propagation levels (REQUIRED, REQUIRES_NEW, NESTED, SUPPORTS, MANDATORY, NEVER, NOT_SUPPORTED) control how nested transactional calls combine; readOnly = true is a hint to Hibernate (skip dirty checking) and the JDBC driver (route to replicas).

Code Example

@Transactional works via a Spring AOP proxy. The proxy consults the PlatformTransactionManager, opens/commits/rolls back a transaction around the method, and uses the Propagation attribute to decide whether to join an existing transaction or start a new one.

@Service
public class OrderService {

    @Transactional                                         // PROPAGATION_REQUIRED (default)
    public void placeOrder(Order o) {
        orderRepo.save(o);
        auditService.record(o);                             // joins same transaction
        notificationService.notify(o);                      // see below
    }
}

@Service
class NotificationService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)  // suspends outer, starts new
    public void notify(Order o) {
        notificationRepo.save(...);                         // commits independently of outer
    }
}

// --- The classic gotcha: self-invocation bypasses the proxy ---
@Service
public class BadService {
    @Transactional public void outer()  { this.inner(); }   // this = raw bean, NOT proxy
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void inner() { /* runs in OUTER's tx, not a new one — proxy skipped! */ }
}

// --- Rollback rules: only RuntimeException triggers rollback by default ---
@Transactional(rollbackFor = Exception.class)              // opt in to checked exceptions
public void transferFunds() throws IOException { ... }

• The proxy exists on the public method of a Spring-managed bean. Calling from inside the same class (this.method()) bypasses it — extract to a separate bean or use AopContext.currentProxy() + @EnableAspectJAutoProxy(exposeProxy=true).
• REQUIRES_NEW commits to the DB before the outer transaction commits, so partial work is durable even if the outer rolls back — use it for audit logs and outbox writes.
• Checked exceptions do not roll back by default. Add rollbackFor = Exception.class or throw a RuntimeException.

Common Mistakes & Pitfalls

Calling a @Transactional method from within the same class bypasses the proxy and the transaction is silently skipped. Candidates often do not mention this self-invocation pitfall.