Spring Internals: Why @Transactional Fails on Private Methods

By The ToolShelf Team January 23, 2026 5 min read

JavaSpring BootArchitectureDebuggingBest Practices

The Silent Failure: When Annotations Don't Work

It is a scenario almost every Spring developer encounters at least once. You are refactoring a large service class, breaking down a complex business operation into smaller, manageable pieces. You extract a specific chunk of logic into a private helper method. Because this helper method modifies the database, you dutifully tag it with @Transactional to ensure data integrity.

The code compiles perfectly. The application starts without warnings. But when you run it, something is wrong. An exception occurs, yet the changes made to the database are not rolled back. The logic ran "naked," completely ignoring your transaction boundaries.

The most confusing part is the silence. Spring didn't throw an initialization error telling you that annotating a private method is invalid. It simply ignored it. This failure isn't magic, and it isn't a bug in the framework. It is a fundamental consequence of Spring's architecture. To understand why your transaction never started, you must stop thinking of annotations as commands and start understanding the machinery of Dynamic Proxies and CGLIB.

It's Not Your Object: Understanding the Spring Proxy Pattern

To understand the failure, we first have to adjust our mental model of Spring's Dependency Injection. When you ask Spring for a bean—for example, by using @Autowired to inject a UserService into a controller—you are rarely holding the actual instance of the UserService class you wrote.

Instead, you are holding a Proxy. Think of this proxy as a security guard or a wrapper that surrounds your actual object. Your code looks like this:

@Autowired
private UserService userService; // This is actually a Proxy

The annotation @Transactional is merely passive metadata. It does nothing on its own. During the application startup, Spring's BeanPostProcessor scans your beans. When it detects annotations like @Transactional, @Cacheable, or @Async, it determines that this bean needs extra behavior. It doesn't modify your original class code; instead, it wraps your bean in a generated proxy.

This proxy handles the "Interception Logic." When an external caller invokes userService.createUser(), the call hits the Proxy first. The Proxy checks the metadata, sees that a transaction is required, opens the database connection, and only then delegates the call to your actual createUser() method. Once your method returns, the Proxy steps back in to commit or rollback the transaction.

Under the Hood: CGLIB and Dynamic Subclassing

How does Spring create this wrapper if it doesn't change your code? Historically, Spring used JDK Dynamic Proxies, which required your classes to implement Interfaces. However, modern Spring Boot applications heavily rely on CGLIB (Code Generation Library), which allows for proxying concrete classes without interfaces.

CGLIB works by generating a dynamic subclass of your bean at runtime. If you have a class named UserService, CGLIB generates a new class in memory that looks something like UserService$$SpringCGLIB$$... which extends UserService.

This generated subclass overrides all public, non-final methods of your parent class. The bytecode magic looks roughly like this (simplified):

public class UserService$$SpringCGLIB extends UserService {
    
    @Override
    public void createUser(User user) {
        // 1. Transaction Manager: Begin Transaction
        try {
            // 2. Call the actual method in the parent class
            super.createUser(user);
            // 3. Transaction Manager: Commit
        } catch (Exception e) {
            // 4. Transaction Manager: Rollback
            throw e;
        }
    }
}

This overriding mechanism is the vehicle that delivers the cross-cutting concerns (like transactions) to your logic.

The 'Private Method' Trap: Java's Inheritance Rules

This brings us to the root of the problem: Java's Inheritance Rules.

Since the CGLIB proxy is strictly a subclass of your bean, it is bound by the laws of the Java language. In Java, private methods are not visible to subclasses. A child class cannot see, access, or—crucially—override a private method of its parent.

When Spring asks CGLIB to generate the proxy, CGLIB scans the UserService class for methods it can override to insert the transaction logic. When it encounters your private helper method, it skips it entirely because it is technically impossible to override it.

Consequently, the generated proxy does not contain a wrapper for your private method. When that method is executed, it is a plain, raw method execution. The proxy machinery that normally handles the BEGIN and ROLLBACK commands is never triggered because the entry point for that machinery (the overridden method) does not exist.

The Self-Invocation Problem: Bypassing the Proxy

There is a secondary trap that catches even experienced developers: Self-Invocation.

Imagine you have a public method registerUser() (no transaction) that calls a public method createUser() (transactional) within the same class.

public class UserService {

    public void registerUser(User user) {
        // Logic...
        this.createUser(user); // @Transactional is ignored here!
    }

    @Transactional
    public void createUser(User user) {
        repo.save(user);
    }
}

Even though createUser is public, the transaction will fail to start. Why?

Remember the "Guard" analogy. The transaction logic only lives in the Proxy. When an external controller calls userService.registerUser(), it goes through the proxy. However, once execution is inside the registerUser method, you are running inside the raw target object.

When you call this.createUser(), this refers to the raw object, not the proxy. You are making a direct internal method call, effectively bypassing the proxy entirely. You have snuck past the security guard. Since the call never passes through the proxy, the AOP interception logic never runs, and the transaction is never opened.

Visualizing the Flow:

External Call: Controller -> Proxy (Intercepts) -> Target.registerUser()
Internal Call: Target.registerUser() -> this.createUser() (Direct call, No Proxy involved)

Summary: Coding for the Proxy

Spring's declarative transaction management is powerful, but it relies on specific architectural patterns—specifically the Proxy Pattern and Method Overriding.

Key Takeaways:

Proxies rely on Overriding: If a method cannot be overridden (private or final), it cannot be proxied.
Private methods are invisible: CGLIB cannot inject logic into methods it cannot see.
Use Public Boundaries: Always define your transaction boundaries at the public API level of your beans.

If you find yourself needing a private method to be transactional, it is usually a sign that your service is doing too much. The architectural solution is to extract that logic into a separate bean. By injecting that new bean and calling it, you force the execution to go through a new Proxy, correctly triggering the transaction logic.

Building secure, privacy-first tools means staying ahead of security threats and understanding your framework internals. At ToolShelf, we believe in robust engineering practices.