What happens when one method in a Spring bean calls another @Transactional method on the same object using this.method()?

## The setup `@Transactional` is not magic on the method itself — Spring makes it work by wrapping your bean in a **proxy**. When you annotate a class or method with `@Transactional`, Spring creates a proxy object that sits *in front of* your real bean. Everywhere you `@Autowired` that bean, you actually receive the **proxy**, not the raw object. The proxy's job: before it delegates to your real method, it asks the `PlatformTransactionManager` to begin a transaction (or join an existing one), and afterwards it commits or rolls back. ## Why self-invocation breaks it The proxy only runs its transaction logic when a call **passes through the proxy**. Two cases: - **External call** — some other bean calls `service.doWork()`. That reference is the proxy, so the transactional wrapper runs. Works. - **Internal call (self-invocation)** — inside `doWork()` you call `this.doInner()` (or just `doInner()`, which is implicitly `this.`). Here `this` is the **raw target object**, not the proxy. The call never leaves the object, never crosses the proxy boundary, so the transaction advice for `doInner()` **is skipped entirely**. So if `doInner()` is `@Transactional(propagation = REQUIRES_NEW)` and you expected a fresh independent transaction, you get nothing — `doInner()` just runs in whatever transaction context `doWork()` already has (possibly none). ```java @Service public class OrderService { @Transactional public void placeOrder() { audit(); // == this.audit(); bypasses proxy } @Transactional(propagation = Propagation.REQUIRES_NEW) public void audit() { // NO new transaction is started here! } } ``` ## Why it is so dangerous It fails **silently**. No exception, no warning at startup — the annotation is simply ignored. Symptoms show up later as: data not rolled back when you expected isolation, an audit row committed together with the failing main transaction (or vice versa), or a read-only flag not applied. ## The three standard fixes 1. **Self-injection** — inject the bean into itself and call through the injected reference (which is the proxy): ```java @Autowired private OrderService self; public void placeOrder() { self.audit(); } ``` Works because `self` is the proxy. Slightly ugly; can be done with `@Lazy` to avoid circular-reference issues, or via `AopContext.currentProxy()` (requires `exposeProxy = true`). 2. **Extract to a separate bean** — move `audit()` into its own `@Service` and inject that. The cross-bean call goes through *its* proxy. This is the cleanest, most-recommended fix and usually improves the design. 3. **Switch to AspectJ weaving** (`@EnableTransactionManagement(mode = AdviceMode.ASPECTJ)` + load-time or compile-time weaving). AspectJ weaves the transaction advice directly into the bytecode of the class instead of using a proxy, so *every* call — including `this.method()` — is intercepted. This removes the limitation entirely but adds build/agent complexity. ## When to use which - Prefer **separate bean** by default — best design, no tricks. - **Self-injection / AopContext** when splitting the class is awkward. - **AspectJ** when you have many self-calls or need the limitation gone project-wide and can accept weaving setup. ## Related gotchas The same proxy limitation applies to `@Async`, `@Cacheable`, `@Retryable`, `@PreAuthorize`, and other proxy-based aspects — internal self-calls bypass all of them. Also note: proxying only works on `public` methods (for CGLIB/JDK proxies); `private`/`final` methods are never proxied either.