Spring AOP: The Mechanism Behind @Transactional

The Pattern You've Already Met Three Times

@Transactional opens a transaction around your method. @Cacheable returns early on a hit. @PreAuthorize throws before your method runs. @Timed records how long it took.

None of those behaviours are in your method body, and all four share one limitation: a self-invocation bypasses them. That isn't a coincidence or four separate bugs. It's one mechanism — aspect-oriented programming — and understanding it explains all four and lets you write your own.

Vocabulary, Briefly

AOP has more jargon than concepts:

So: an aspect contains advice that runs at join points selected by a pointcut.

Spring AOP Is Proxies

Spring does not rewrite your bytecode. It wraps your bean in a proxy that implements the same interface (or subclasses the class), and the proxy runs the advice before delegating.

The dotted arrow is the whole story. A call to this.other() goes straight to the target, never through the proxy, so no advice runs.

Two proxy mechanisms, chosen automatically:

• JDK dynamic proxies — when the bean implements an interface. The proxy implements the same interface.
• CGLIB — otherwise. The proxy is a generated subclass.

Spring Boot defaults to CGLIB for everything (spring.aop.proxy-target-class: true), which avoids the classic "expected OrderService but got a Proxy" injection failure.

What proxying cannot intercept

That first row is the one that causes production bugs, and it's worth being able to spot in review. @Transactional on a self-called method means no transaction. @PreAuthorize on a self-called method means no authorisation check — a security hole that looks like working code.

Writing an Aspect

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-aop'
}

A custom annotation plus an aspect that acts on it:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Audited {
    String action();
}

@Aspect
@Component
public class AuditAspect {
 
    private static final Logger log = LoggerFactory.getLogger(AuditAspect.class);
    private final AuditRepository repository;
 
    public AuditAspect(AuditRepository repository) {      // aspects are beans
        this.repository = repository;
    }
 
    @Around("@annotation(audited)")
    public Object audit(ProceedingJoinPoint joinPoint, Audited audited) throws Throwable {
        String user = SecurityContextHolder.getContext().getAuthentication().getName();
        long start = System.nanoTime();
        try {
            Object result = joinPoint.proceed();          // call the target
            repository.save(AuditEntry.success(audited.action(), user,
                    Duration.ofNanos(System.nanoTime() - start)));
            return result;
        } catch (Throwable ex) {
            repository.save(AuditEntry.failure(audited.action(), user, ex.getClass().getSimpleName()));
            throw ex;                                     // never swallow
        }
    }
}

@Audited(action = "ORDER_CANCELLED")
public void cancel(Long orderId) { }

Two things that must be right in @Around advice. Call proceed() exactly once — forget it and the target method never runs, which is a confusing bug because the method appears to succeed and do nothing. And rethrow, or you convert every exception into a silent success.

Advice types

@Around is the most powerful and the only one that can skip the method, change the arguments, or alter the return value — which is how @Cacheable returns a cached value without executing anything.

Pointcut expressions

@Pointcut("execution(* com.example.shop..*Service.*(..))")
void anyServiceMethod() {}
 
@Pointcut("@annotation(org.springframework.transaction.annotation.Transactional)")
void transactionalMethod() {}
 
@Pointcut("within(com.example.shop.order..*)")
void inOrderPackage() {}
 
@Pointcut("@within(org.springframework.stereotype.Service)")
void inAnyServiceClass() {}
 
@Before("anyServiceMethod() && !transactionalMethod()")
void warnOnUntransactionalServiceCall() {}

The execution wildcards read as: return type, package (.. for any depth), class, method, arguments (.. for any). Named @Pointcut methods compose with &&, || and !, which keeps expressions readable — an inline expression repeated across six advice methods is six places to update.

Ordering

Multiple aspects on one method need a defined order:

@Aspect
@Component
@Order(1)        // lower runs first on the way in, last on the way out
public class AuditAspect { }

Ordering is not cosmetic when aspects interact with transactions. An audit aspect ordered inside @Transactional has its write rolled back with the business transaction — which may be exactly wrong for a failure audit. @Transactional runs at Ordered.LOWEST_PRECEDENCE by default, so your aspects are typically outside it unless you say otherwise. If the audit must survive, combine the ordering with Propagation.REQUIRES_NEW as the transactions guide describes.

When to Use AOP

The honest answer is: rarely, and for a narrow class of problem.

Good uses share a shape — behaviour that is genuinely orthogonal to business logic, applies uniformly across many methods, and would otherwise be copy-pasted:

• Audit logging of specific operations
• Timing and metrics (@Timed is this)
• Retry around a declared annotation
• Enforcing an architectural rule in tests

Poor uses are where AOP hides something a reader needs to know:

• Business logic. An aspect that modifies a result or adds a rule makes behaviour invisible at the call site. Someone debugging will read the method, see the expected code, and not find the cause.
• Universal logging. An aspect that logs entry and exit of every method produces unreadable volume and duplicates what tracing already does better, with context.
• Anything already provided. @Transactional, @Cacheable, @Retryable, @Timed and method security are all AOP, already written and tested.

AspectJ, If You Need More

Spring AOP's limitations come from proxies. Full AspectJ weaves advice into bytecode and so can intercept self-calls, private methods, field access and constructors.

It costs a compile-time or load-time weaving step, an extra toolchain, and considerably harder debugging — stack traces include woven code that isn't in your source.

For the overwhelming majority of applications, proxy-based AOP is sufficient and the right call. If you find yourself needing AspectJ to intercept a self-call, the structural fix — splitting the bean — is usually better than the weaving.

The Mental Model, Restated

1. Spring AOP is proxies, not bytecode rewriting.
2. Self-invocation, private, final and static methods cannot be intercepted — silently.
3. @Transactional, @Cacheable, @PreAuthorize and @Timed are all AOP, which is why they share that limitation.
4. @Around must call proceed() once and rethrow.
5. Prefer @annotation pointcuts to broad execution patterns.
6. Mind the ordering relative to @Transactional.
7. Use AOP for orthogonal concerns, never for business logic.

What's Next

Aspects decouple cross-cutting behaviour from a method, but the call is still synchronous and in-process. The next guide covers decoupling in a different direction: Spring's application events for in-process publish/subscribe — including the transactional event listener that solves a problem you've already met — and the step up to real message brokers.