@Transactional is a proxy: self-invocation and other traps

@Transactional is metadata. Nothing in the annotated class begins or commits anything. What does the work is a proxy: when Spring creates a bean that has transactional methods, it hands other beans a proxy object instead of the bean itself. For each call to a transactional method the proxy:

1. asks the PlatformTransactionManager for a transaction (joining an existing one or starting a new one, depending on propagation), which binds a database connection to the current thread;
2. calls the real method on the target bean;
3. commits if the method returns, or rolls back if it throws an exception that the rollback rules cover (next lesson).

Spring Boot creates class-based (CGLIB subclass) proxies by default; without Boot, a bean implementing an interface may get a JDK dynamic proxy instead. Either way, the rule is the same: only calls that go through the proxy are intercepted.

Self-invocation

@Service
public class OrderService {
    public void placeOrder(Order o) {     // not transactional
        validate(o);
        this.save(o);                     // a plain Java call: no proxy involved
    }

    @Transactional
    public void save(Order o) { ... }     // runs WITHOUT a transaction here
}

A controller calls placeOrder on the proxy. The proxy sees no annotation on placeOrder and simply delegates to the target. Inside the target, this.save(o) is an ordinary method call on the target object itself; the proxy never sees it, so no transaction starts. The example builds a real JDK dynamic proxy with a home-made @Tx annotation and shows exactly this:

1import java.lang.annotation.*;2import java.lang.reflect.*;3import java.util.*;4 5public class Solution {6    @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD)7    @interface Tx {}8 9    static final List<String> log = new ArrayList<>();10    static boolean txActive = false;           // stands in for the thread-bound transaction11 12    public interface OrderService {13        void placeOrder();14        void save();15    }16 17    static final class OrderServiceImpl implements OrderService {18        public void placeOrder() {19            log.add("placeOrder runs, transaction active=" + txActive);20            this.save();                       // self-invocation21        }22        @Tx23        public void save() {24            log.add("save runs, transaction active=" + txActive);25        }26    }27 28    static OrderService proxy(OrderService target) {29        InvocationHandler h = (p, method, args) -> {30            Method impl = target.getClass().getMethod(method.getName(), method.getParameterTypes());31            if (!impl.isAnnotationPresent(Tx.class)) return method.invoke(target, args);32            log.add("proxy: begin");33            txActive = true;34            try {35                Object result = method.invoke(target, args);36                log.add("proxy: commit");37                return result;38            } finally {39                txActive = false;40            }41        };42        return (OrderService) Proxy.newProxyInstance(43            OrderService.class.getClassLoader(), new Class<?>[]{OrderService.class}, h);44    }45 46    public static List<String> run() {47        OrderService service = proxy(new OrderServiceImpl());   // what other beans receive48        log.add("--- controller calls placeOrder()");49        service.placeOrder();50        log.add("--- controller calls save() directly");51        service.save();52        return log;53    }54}

The same applies to @Cacheable, @Async, @PreAuthorize and @Retryable: anything implemented by a proxy is skipped by self-invocation.

Fixes

• Move the method to another bean and inject it. The call then goes through that bean's proxy. This is usually also the better design.
• Put the annotation on the outer method (placeOrder) when the whole operation should be one transaction anyway.
• Use a TransactionTemplate for a programmatic transaction around exactly the code that needs it.
• Inject the bean's own proxy (@Lazy self-injection) — it works, but it is a workaround that hides the structure.

What else a proxy cannot see

A class-based proxy is a subclass, so it cannot override private or final methods: annotating them has no effect. Since Spring Framework 6.0, @Transactional on a protected or package-private method also takes effect with a class-based proxy (before 6.0 only public methods counted); an interface-based JDK proxy still sees only the public interface methods, so public remains the safe convention. And because the transaction is bound to the thread, work handed to another thread — an @Async method, a CompletableFuture, a parallel stream — does not run in the caller's transaction.

Common mistakes

• Annotating a helper method and calling it from the same class, as in the example: no transaction, and no error to tell you.