Kodivio

@Transactional Self-Invocation Trap

Why calling a @Transactional method from within the same class silently skips transaction management — and how to architect around it.

Framework
Spring Boot 3.x
Runtime
Java 21 LTS
Stability
Enterprise grade

Overview

Spring's @Transactional is powered by AOP proxies: when you inject a @Service, you actually receive a CGLIB-generated subclass that wraps your bean. Every external method call goes through this proxy, which intercepts @Transactional methods and wraps them in a transaction. But when you call a @Transactional method from another method in the same class using 'this', you bypass the proxy entirely. The result is silent: no exception, no warning — just your changes not being committed to the database.

Symptom

exception_report.logFatal
// No exception thrown — changes silently not persisted
class="hi-ann">@Service
public class OrderService {

    public void processOrder(Order order) {
        validateOrder(order);  // OK
        saveOrder(order);      // ⚠️ NO TRANSACTION — bypasses the proxy!
    }

    class="hi-ann">@Transactional
    public void saveOrder(Order order) {
        orderRepository.save(order);
        // Data lost if an exception occurs — no rollback context exists
    }
}

Root cause

AOP proxies only intercept method calls that originate from outside the bean. The call chain processOrder() → saveOrder() never leaves the actual target object — it calls this.saveOrder() directly, bypassing the CGLIB proxy that would have started the transaction. Spring has no hook into this internal call path.

Resolution

  1. Extract the @Transactional method into a separate @Service bean — the call from the original service now goes through the proxy.

  2. Use TransactionTemplate for programmatic transaction control when you need transactional boundaries within a single class.

  3. Self-inject the service via @Autowired and call through the self-reference — ugly but effective as a last resort.

  4. Refactor the class to ensure all transactional entry points are called from other Spring-managed beans.

  5. Switch to AspectJ compile-time or load-time weaving for scenarios where proxy-based AOP is a genuine structural constraint.

Production implementation
SafeJava 21
// ❌ THE INVISIBLE BUG — self-invocation skips the proxy
class="hi-ann">@Service
public class OrderService {
    public void processOrder(Order order) {
        saveOrder(order); // 'this.saveOrder()' — proxy never sees this call
    }

    class="hi-ann">@Transactional
    public void saveOrder(Order order) { ... } // Transaction NEVER starts
}

// ✅ SOLUTION 1: Service Extraction (Recommended)
class="hi-ann">@Service
class="hi-ann">@RequiredArgsConstructor
public class OrderService {
    private final OrderPersistenceService persistence;

    public void processOrder(Order order) {
        validateOrder(order);
        persistence.saveOrder(order); // Hits the proxy — transaction starts ✅
    }
}

class="hi-ann">@Service
public class OrderPersistenceService {
    class="hi-ann">@Transactional
    public void saveOrder(Order order) {
        orderRepository.save(order);
    }
}

// ✅ SOLUTION 2: TransactionTemplate (Programmatic control)
class="hi-ann">@Service
class="hi-ann">@RequiredArgsConstructor
public class OrderService {
    private final TransactionTemplate txTemplate;

    public void processOrder(Order order) {
        txTemplate.execute(status -> {
            orderRepository.save(order);
            return null;
        });
    }
}

Deep dive

How CGLIB Proxies Work

Spring uses CGLIB to subclass your class="hi-ann">@Service bean at startup. The generated subclass overrides each class="hi-ann">@Transactional method to inject transaction begin/commit/rollback logic around a super.methodName() call. When another bean calls your service, it calls the subclass's override. When your service calls itself internally, it calls the real this — the superclass instance — bypassing all overrides.

AspectJ Weaving: The Nuclear Option

AspectJ weaving injects transaction logic directly into your class's bytecode at compile time (CTW) or class-loading time (LTW). Self-invocation works perfectly with AspectJ because there's no proxy — the instrumented method body itself contains the transaction setup. The tradeoff: a more complex build pipeline and load-time agent configuration. For most teams, Service Extraction is far simpler.

Detecting This Silently Failing Bug

Write integration tests using class="hi-ann">@DataJpaTest or class="hi-ann">@SpringBootTest that verify data is persisted after calling the outer (non-transactional) method. Mock-based unit tests will never catch this class of bug because they don't go through the Spring proxy infrastructure.

Best practices

  1. Write at least one integration test per service class that verifies database state — unit tests with mocks will never catch proxy-bypass issues.

  2. Apply the Single Responsibility Principle rigorously: a method that orchestrates should not also be the transactional boundary.

  3. Use @Transactional(readOnly = true) as the default on all service classes; override with @Transactional on write methods to make the contract explicit.

FAQ

What causes @Transactional Self-Invocation Trap in Spring Boot 3?
AOP proxies only intercept method calls that originate from outside the bean. The call chain processOrder() → saveOrder() never leaves the actual target object — it calls this.saveOrder() directly, bypassing the CGLIB proxy that would have started the transaction. Spring has no hook into this internal call path.
How do I fix @Transactional Self-Invocation Trap?
Extract the @Transactional method into a separate @Service bean — the call from the original service now goes through the proxy. Use TransactionTemplate for programmatic transaction control when you need transactional boundaries within a single class. Self-inject the service via @Autowired and call through the self-reference — ugly but effective as a last resort. Refactor the class to ensure all transactional entry points are called from other Spring-managed beans. Switch to AspectJ compile-time or load-time weaving for scenarios where proxy-based AOP is a genuine structural constraint.
Best practice #1 for preventing Spring AOP · Transactions errors?
Write at least one integration test per service class that verifies database state — unit tests with mocks will never catch proxy-bypass issues.
Best practice #2 for preventing Spring AOP · Transactions errors?
Apply the Single Responsibility Principle rigorously: a method that orchestrates should not also be the transactional boundary.
Best practice #3 for preventing Spring AOP · Transactions errors?
Use @Transactional(readOnly = true) as the default on all service classes; override with @Transactional on write methods to make the contract explicit.

Related errors

⬡

Understanding Spring's Proxy Model to Avoid Self-Invocation Traps

Spring's declarative transaction support is elegant precisely because it is invisible — you annotate a method @Transactional and Spring ensures a transaction is opened, committed, or rolled back without a single line of boilerplate. What makes this magic possible is also what makes self-invocation a silent failure mode: Spring wraps your bean inside a proxy object, and calls that enter from outside go through that proxy. When a method inside the same class calls another method in the same class, the call goes directly to this — the raw, unwrapped instance — completely bypassing every piece of AOP advice attached to it.

⚠ Why the Stack Trace Gives You Nothing

There is no exception, no warning, no log line. The inner method runs, database writes happen, and everything appears to work — until you check the database under a failure scenario and discover that rows written by the inner method were not rolled back because they were never enrolled in the outer transaction. In high-stakes domains like payment processing or inventory management this has caused real financial discrepancies that only surfaced during month-end reconciliation.

The Three Safe Patterns

01

Split into a separate Spring bean

The cleanest solution is architectural. This is not a hack — it is a design signal that the inner operation has its own transactional identity and belongs in its own service.

02

Self-inject the proxied bean

Inject self via @Autowired or ApplicationContext.getBean(). Works, but carries a code smell that reviewers will flag and signals the class is doing too many things.

03

AopContext.currentProxy()

The most explicit option — reaching outside the bean model entirely. Treat as a last resort for legacy code you cannot refactor.

The best regression guard is an integration test that deliberately triggers a rollback in the outer transaction and then asserts that all rows — including those written by the inner method — were rolled back. Use @DataJpaTest with a real database rather than a mock, because @MockBean will hide the bug by bypassing the actual transaction infrastructure. For teams that want to prevent the pattern from reappearing, an ArchUnit rule that checks "no method annotated @Transactional shall be called from a method in the same class" can be expressed in a few lines and will fail the build if a developer inadvertently reintroduces the pattern.

Kodivio Team
Kodivio Team

AI & Web Development Specialists

The Kodivio team covers AI tools, automation, and modern web development based on real-world testing and hands-on experience.

Learn more about us →