Spring AOP
Deep Dive

Root cause: CGLIB is the default proxy strategy in Spring Boot 2+. If your service class is declared final, CGLIB cannot create a subclass — startup fails.

• Remove final from the class or use an interface + switch to JDK proxy
• Add spring.aop.proxy-target-class=false in application.properties to force JDK proxy
• If using Kotlin — Kotlin classes are final by default! Add kotlin-allopen plugin or annotate with open

// build.gradle.kts
plugins {
    kotlin("plugin.allopen") version "1.9.0"
}
allOpen {
    annotation("org.springframework.stereotype.Service")
    annotation("org.springframework.transaction.annotation.Transactional")
}

This is a very common production issue. A timing aspect with a broad pointcut like execution(* *.*(..)) accidentally intercepts Spring infrastructure beans, repository calls, and even Hibernate internal methods — causing enormous overhead.

Debugging steps:

• Enable logging.level.org.springframework.aop=DEBUG to see which proxies are created
• Use -Dspring.aop.proxy-target-class=true and check proxy chain depth
• Add a within() scope constraint to narrow down the pointcut

@Pointcut("execution(* *.*(..))")  // catches EVERYTHING including Spring internals

@Pointcut("execution(* com.mycompany.app..*(..)) "
    + "&& !within(com.mycompany.app.config..*)"
    + "&& !within(com.mycompany.app.aspect..*)")  // exclude aspects themselves!
public void applicationLayer() {}

A common trap: @AfterThrowing will only fire if the exception propagates out of the proxied method. If the method catches it internally and swallows it, the aspect never sees it.

public void processPayment() {
    try {
        gateway.charge();
    } catch (Exception e) {
        log.error("Payment failed", e);  // swallowed! Aspect never sees this
    }
}

@AfterThrowing(pointcut = "execution(* com.app.service.*.*(..))",
               throwing = "ex")
public void alertOnException(Exception ex) {
    // This NEVER fires because exception was caught above
    alertingService.notify(ex);
}

This is the most asked AOP question in senior Java interviews — and the most common production bug.

The Problem: Spring AOP works by wrapping beans in proxies. When code OUTSIDE the bean calls a method, it goes through the proxy (aspects fire). But when a method inside the bean calls another method of the same bean using this, it bypasses the proxy entirely — no aspects, no @Transactional.

@Service
public class OrderService {

    public void placeOrder(Order order) {
        // Called from controller → goes through proxy ✓
        saveOrder(order);    // ← this.saveOrder() — BYPASSES PROXY ✗
                              // @Transactional on saveOrder does NOTHING
    }

    @Transactional
    public void saveOrder(Order order) {
        // Called from placeOrder() via 'this' — not the proxy
        // No transaction context! Any DB write here can fail silently
        repo.save(order);
    }
}

Fix 1: Inject self (ApplicationContext)

@Service
public class OrderService {

    @Autowired
    private OrderService self;  // Spring injects the PROXY, not 'this'

    public void placeOrder(Order order) {
        self.saveOrder(order);   // ← goes through proxy ✓ TX active!
    }

    @Transactional
    public void saveOrder(Order order) {
        repo.save(order);         // Now has proper transaction boundary
    }
}

Fix 2: AopContext.currentProxy()

@EnableAspectJAutoProxy(exposeProxy = true)  // needed in @Configuration
public class AppConfig {}

@Service
public class OrderService {
    public void placeOrder(Order order) {
        ((OrderService) AopContext.currentProxy()).saveOrder(order);
    }

    @Transactional
    public void saveOrder(Order order) { repo.save(order); }
}

Fix 3: Refactor to separate bean (Recommended)

@Service
public class OrderService {
    @Autowired
    private OrderPersistenceService persistSvc;

    public void placeOrder(Order order) {
        persistSvc.saveOrder(order);  // external call → proxy → TX fires ✓
    }
}

@Service
public class OrderPersistenceService {
    @Transactional
    public void saveOrder(Order order) { repo.save(order); }
}

Spring AOP proxies can only intercept public methods. A @Transactional on a private, protected, or package-private method is silently ignored — no exception, no warning by default.

@Service
public class UserService {

    @Transactional              // ← IGNORED. Spring AOP can't proxy private methods
    private void createUserInternal(User u) {
        userRepo.save(u);      // No rollback on exception. Data corruption risk.
        auditRepo.log(u);
    }

    public void createUser(User u) {
        createUserInternal(u);   // This is just a plain method call
    }
}

Enable this warning explicitly:

# application.properties
spring.jpa.open-in-view=false
logging.level.org.springframework.transaction=DEBUG
# Use AspectJ compile-time weaving to support private method TX
# (rarely justified — refactor is always better)

By default, Spring only rolls back on unchecked exceptions (RuntimeException and Error). Checked exceptions are treated as "expected" failures — transaction commits!

@Transactional
public void transferFunds(long fromId, long toId, BigDecimal amount)
        throws InsufficientFundsException {  // ← checked
    debit(fromId, amount);  // DB write succeeds
    if (balance < 0) {
        throw new InsufficientFundsException("Not enough funds");
        // TX COMMITS! debit already happened. Money gone.
    }
    credit(toId, amount);
}

@Transactional(rollbackFor = Exception.class)
public void transferFunds(...) throws InsufficientFundsException {
    // Now checked exceptions also trigger rollback
}

// Or be specific:
@Transactional(rollbackFor = {InsufficientFundsException.class, PaymentException.class})
public void transferFunds(...) { ... }

Root cause: The Hibernate session closes when the @Transactional method returns. Accessing lazy-loaded collections in the controller/view layer (after TX ends) triggers this.

@Transactional
public User getUser(long id) {
    return userRepo.findById(id).get();  // session closes after return
}

// In controller — session is GONE
User user = userService.getUser(1L);
user.getOrders().size();  // LazyInitializationException!

Solution 1: Eager fetch in query (best for specific use cases)

@Query("SELECT u FROM User u JOIN FETCH u.orders WHERE u.id = :id")
User findByIdWithOrders(@Param("id") Long id);

Solution 2: Use DTOs — never expose entities to the view layer

@Transactional(readOnly = true)
public UserDTO getUser(long id) {
    User u = userRepo.findById(id).get();
    return new UserDTO(u.getId(), u.getOrders());  // accessed within TX
}

Solution 3: @Transactional(readOnly=true) on controller (anti-pattern — avoid)

// Never use open-session-in-view = true in prod (lazy loads on serialization — N+1)
spring.jpa.open-in-view=false  // Always set this in application.properties

Root cause: Inner @Transactional (REQUIRED) method catches an exception and rethrows it. Spring marks the TX as rollback-only. The outer caller catches it and tries to commit — but TX is already poisoned.

@Transactional  // Outer — TX-1
public void outerMethod() {
    try {
        innerService.innerMethod();  // throws → TX-1 marked rollback-only
    } catch (Exception e) {
        // we handle it — but TX is already poisoned
        log.warn("Handled", e);
    }
    orderRepo.save(order);  // TX-1 commit attempted
    // → UnexpectedRollbackException! TX was rollback-only
}

@Transactional  // REQUIRED — joins TX-1, not a new TX
public void innerMethod() {
    throw new RuntimeException("Inner failed");  // marks TX-1 rollback-only
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void innerMethod() {
    // Separate TX-2 — if this rolls back, TX-1 is unaffected
}

Two causes: (1) Aspect pointcut matches the aspect itself — the aspect advises its own methods, creating infinite recursion. Fix: add && !within(com.app.aspect..*) to exclude aspect package. (2) Aspect calls a Spring bean method that is also matched by the same pointcut — the aspect triggers itself through the proxy chain.

@Pointcut("execution(* com.app..*(..)) && !within(com.app.aspect..*)")
public void appMethods() {}

// Cause 2 — aspect calls service that matches its own pointcut
// Fix: use a separate logger/service that is outside the pointcut scope
// or inject via @Autowired and check isProxy before calling