Does Spring @Transactional Annotation Work on a Private Method?

1. Overview

In this tutorial, we’ll resolve the question of whether Spring’s @Transactional annotation works on private methods. As a cornerstone of transaction management in Spring applications, @Transactional simplifies ensuring data consistency across database operations. However, developers often encounter unexpected behavior when applying it, leading to questions about its compatibility with method visibility.

We’ll delve into Spring’s transaction management mechanics and provide clear explanations and practical insights to address this.

2. Understanding Spring’s @Transactional Annotation

The @Transactional annotation in Spring is used to define transactional boundaries around methods or classes. It ensures that operations within the annotated scope are executed as a single unit of work. When a method annotated with @Transactional is invoked, Spring’s transaction management creates a transaction, handles commits or rollbacks, and manages resources like database connections.

2.1. Example Service Method

Let’s look at a code example, where we apply the annotation on a service method:

@Service
public class OrderService {
    @Autowired
    private TestOrderRepository repository;
    @Transactional
    public void createOrder(TestOrder order) {
        repository.save(order);
    }
}

When we apply @Transactional to the createOrder method, it doesn’t execute any logic itself; instead, it serves as a marker. Spring’s Aspect-Oriented Programming (AOP) framework processes this marker using proxies to intercept method calls and weave in transactional behavior.

Let’s dive into what these proxies are and how they tie into @Transactional.

2.2. Aspects and Proxies

A proxy acts as an intermediary object that wraps a target object to intercept and control access to its methods. It can enable additional behavior, like transaction management.

To illustrate a custom @Transactional aspect, let’s consider a simplified example:

@Around("@annotation(org.springframework.transaction.annotation.Transactional)")
public Object manageTransaction(ProceedingJoinPoint joinPoint) throws Throwable {
    // Start transaction
    try {
        Object result = joinPoint.proceed(); // Execute the target method, like 'createOrder'
        // Commit transaction
        return result;
    } catch (Throwable t) {
        // Rollback transaction
        throw t;
    }
}

This code example illustrates an interception function, manageTransaction, that mimics @Transactional behavior. Using the @Around advice, it intercepts methods annotated with @Transactional annotation, initiating a transaction before execution, committing it upon success, or rolling it back on failure.

Method visibility – public, protected, package-private, or private – plays a significant role, detecting the methods to be intercepted.

With this foundation, let’s tackle the core question: Does @Transactional work on private methods?

3. Does @Transactional Work on private Methods?

The short answer is: No, not by default.

To understand why, let’s examine how Spring’s AOP proxies work. These proxies wrap the target object to intercept calls and add transactional logic around the method.

However, proxies can only intercept methods they can access, which traditionally means public methods.

As of Spring 6.0, @Transactional also supports protected and package-visible methods in class-based proxies. But note: For interface-based proxies (JDK dynamic proxies), methods must still be public and defined in the interface.

Why do these limitations exist?

3.1. The Role of Method Visibility

Spring uses two main proxy types for @Transactional: JDK dynamic proxies (interface-based, requiring an interface implementation) and CGLIB proxies (class-based, via subclassing). Neither can intercept private methods – or effectively private ones like final or static methods.

To determine which proxy mode an application uses, note that Spring defaults to JDK dynamic proxies if the bean implements an interface; otherwise, it uses CGLIB. We can force CGLIB by setting proxyTargetClass=true in @EnableTransactionManagement or in our AOP config.

In Java, private methods aren’t inherited and can’t be overridden. So, when we annotate a private method with @Transactional, the proxy can’t see or intercept it, and the transactional behavior is skipped.

3.2. What Happens if We Annotate private Methods Anyway?

To demonstrate, let’s add methods with varying visibilities to our OrderService. Each saves an order and throws an exception. If @Transactional works, the exception should trigger a rollback, leaving the repository empty. If not, the order persists.

First, let’s focus on the private method, as it’s the core case where we expect failure:

@Transactional
private void createOrderPrivate(TestOrder order) {
    repository.save(order);
    throw new RuntimeException("Rollback createOrderPrivate");
}
public void callPrivate(TestOrder order) {
    createOrderPrivate(order);
}

Now, let’s test this. We call the private method indirectly via a public wrapper, since private methods aren’t directly callable from outside:

@Test
void givenPrivateTransactionalMethod_whenCallingIt_thenShouldNotRollbackOnException() {
    assertThat(repository.findAll()).isEmpty();
    assertThatThrownBy(() -> underTest.callPrivate(new TestOrder())).isNotNull();
    assertThat(repository.findAll()).hasSize(1);
}

Here, the repository ends up with one order after the exception, showing no rollback, indicating that @Transactional was ignored because the proxy couldn’t intercept the private method.

Next, let’s contrast this with the behavior of a public method:

@Transactional
public void createOrderPublic(TestOrder order) {
    repository.save(order);
    throw new RuntimeException("Rollback createOrderPublic");
}

@Test
void givenPublicTransactionalMethod_whenCallingIt_thenShouldRollbackOnException() {
    assertThat(repository.findAll()).isEmpty();
    assertThatThrownBy(() -> underTest.createOrderPublic(new TestOrder())).isNotNull();
    assertThat(repository.findAll()).isEmpty();
}

This time, the repository stays empty post-exception, confirming the rollback worked via proxy interception.

Similarly, for package-private (default visibility):

@Transactional
void createOrderPackagePrivate(TestOrder order) {
    repository.save(order);
    throw new RuntimeException("Rollback createOrderPackagePrivate");
}

@Test
void givenPackagePrivateTransactionalMethod_whenCallingIt_thenShouldRollbackOnException() {
    assertThat(repository.findAll()).isEmpty();
    assertThatThrownBy(() -> underTest.createOrderPackagePrivate(new TestOrder())).isNotNull();
    assertThat(testOrderRepository.findAll()).isEmpty();
}

Assuming we’re using class-based proxies (CGLIB), this rolls back as expected in Spring 6.0+.

Finally, let’s test the @Transatcional annotation’s behavior for protected methods:

@Transactional
protected void createOrderProtected(TestOrder order) {
    repository.save(order);
    throw new RuntimeException("Rollback createOrderProtected");
}

@Test
void givenProtectedTransactionalMethod_whenCallingIt_thenShouldRollbackOnException() {
    assertThat(repository.findAll()).isEmpty();
    assertThatThrownBy(() -> underTest.createOrderProtected(new TestOrder())).isNotNull();
    assertThat(testOrderRepository.findAll()).isEmpty();
}

Again, rollback succeeds with class-based proxies.

Ultimately, @Transactional is just metadata – a marker for Spring’s runtime to act on. If the proxy can’t detect it (as with private methods), it’s as if the annotation isn’t there: The method runs without transactions.

4. How to Resolve the Issue with private Methods

Since @Transactional doesn’t work on private methods, we need workarounds to avoid issues like missed rollbacks.

Let’s explore a few options.

4.1. Use public Methods

The simplest fix is to move the logic to a public method, which proxies can reliably intercept.

That said, making methods public might break encapsulation. To balance this, design interfaces thoughtfully or use package-private methods (supported in Spring 6.0+ with CGLIB).

4.2. Switch to AspectJ Weaving

For more flexibility, we can use AspectJ, which weaves aspects directly into bytecode at compile- or load-time, bypassing proxy limits.

This approach allows @Transactional to work on private methods but requires additional configuration, such as enabling AspectJ weaving.

4.3. Extract to a Separate Bean

Another approach is to extract the transactional logic into a separate Spring bean with a public method. Then, inject this bean into the original service and call it. This preserves encapsulation in the main class while letting the proxy handle the new public method.

5. Conclusion

In this article, we explored Spring’s @Transactional annotation and its limitations with private methods, stemming from proxy-based AOP. Proxies can’t access private methods, so the annotation gets ignored.

We can overcome this with public methods, AspectJ weaving, or separate beans. By grasping these mechanics and choosing the right fix, we ensure reliable transactions in our Spring applications.

As always, the entire code used in this article can be found over on GitHub.