Proxy Pattern — How Spring AOP Implements It

The Proxy pattern places an intermediary between the caller and the real object. The proxy implements the same interface or extends the same class, so callers can't tell the difference. Inside the proxy, infrastructure logic runs before and after delegating to the real method — this is how cross-cutting concerns like transactions, caching, and security are applied without polluting business code.

Spring AOP is a production-scale implementation. When you annotate a method with @Transactional, Spring wraps the entire bean in a proxy at startup. Every call from outside goes through the proxy, which starts a transaction, delegates to your method, and commits or rolls back. @Cacheable, @Async, and @PreAuthorize work the same way.

Spring chooses between two proxy strategies. JDK dynamic proxies generate a class that implements the bean's interfaces — you must inject by interface type. CGLIB generates a subclass at runtime and is the default since Spring Boot 2.0. CGLIB can't proxy final classes or methods because it relies on subclassing.

The most important practical consequence is the self-invocation trap. If a @Transactional method calls another @Transactional method in the same class using this.method(), the call goes directly to the real object, bypassing the proxy. The transaction annotation on the inner call is silently ignored. The cleanest fix is moving the method to a separate bean so the call crosses bean boundaries and routes through the proxy.