Self-Invocation Bypasses the Proxy

## The mechanism Spring's declarative features like `@Transactional`, `@Cacheable`, `@Async`, and custom `@Aspect` advice are implemented with **AOP proxies**. When a bean needs advice, Spring does not hand other beans the raw object. Instead it wraps it in a **proxy** — either a JDK dynamic proxy (if the bean implements an interface) or a CGLIB subclass proxy (the default for classes). The proxy has the same type/methods as your bean. Every method it exposes first runs the **interceptor chain** (e.g. `TransactionInterceptor` opens a transaction, `CacheInterceptor` checks the cache) and then delegates to the real target object. Key fact: **advice only runs when a call passes through the proxy.** External beans hold a reference to the proxy, so their calls are advised. But inside the target object, `this` refers to the **raw, unwrapped instance** — not the proxy. So any call written as `this.method()` (and `method()` with an implicit `this`) goes straight to the target and **bypasses the entire interceptor chain**. ## The classic symptom ```java @Service public class OrderService { public void placeOrder(Order o) { validate(o); save(o); // this.save(o) -> NO transaction! } @Transactional public void save(Order o) { repo.persist(o); } } ``` Calling `orderService.placeOrder()` from a controller goes through the proxy, but `placeOrder` itself is not transactional. The nested `save(o)` is an internal `this` call, so `TransactionInterceptor` never fires. `save` runs with **no transaction**. There is no exception and no log line — the `@Transactional` is silently ineffective. The same happens with `@Cacheable`: the cache is never consulted or populated for internal calls. ## Why it happens (proxy vs target) Proxy-based AOP is **caller-side** interception: the decision to run advice is made when someone *invokes a method on the proxy reference*. The target has no knowledge that it is proxied and cannot route its own calls back through the wrapper. This is a fundamental limitation of proxy-based AOP, documented explicitly in the Spring reference under 'Understanding AOP Proxies'. ## Fixes 1. **Refactor into a separate bean (preferred).** Move the annotated method to another `@Service`/`@Component` and inject it. The call is now external, so it goes through that bean's proxy. Cleanest and most testable. 2. **Self-injection.** Inject the bean into itself (Spring gives you the proxy) and call through that reference: ```java @Autowired private OrderService self; ... self.save(o); // goes through proxy ``` Works, but is a bit of a smell and needs the field-injected proxy (setter/field, not constructor, to avoid a circular-constructor problem — or use `@Lazy` on a constructor param). 3. **`AopContext.currentProxy()`.** Enable `@EnableAspectJAutoProxy(exposeProxy = true)` (or `exposeProxy=true` on `<aop:config>` / transaction proxy) and call `((OrderService) AopContext.currentProxy()).save(o)`. It ties your code to Spring AOP, so use sparingly. 4. **AspectJ weaving (compile-time or load-time).** With real AspectJ (`@EnableLoadTimeWeaving` + `spring-aspects`, or the AspectJ compiler), advice is woven **into the bytecode of the method itself**, not into a wrapper. Because there is no proxy, self-invocation is advised correctly. Heavier setup, but the only approach that fully removes the limitation. ## Edge cases and gotchas - Applies to **all** proxy-based advice, not just transactions: `@Cacheable`, `@CacheEvict`, `@Async`, `@Retryable`, `@PreAuthorize`, custom aspects. - `private`/`final` methods can't be advised by CGLIB either — separate but related gotcha. - Same-class calls to a **different** annotated method still self-invoke; the problem is `this`, not same-method recursion specifically. - Different `@Transactional` **propagation** (e.g. `REQUIRES_NEW`) is also ignored on self-invocation — a common trap when someone expects a new inner transaction. - Constructor-based self-injection can cause a circular dependency error; use field/setter injection or `@Lazy`. ## When to use which fix Refactor to a separate collaborator for clean designs. Use self-injection or `exposeProxy` for a quick, localized fix. Choose AspectJ only when you genuinely need fine-grained/internal advice project-wide and accept the build/agent complexity.