Spring @Transactional: Propagation Behaviors, Rollback Mechanism, and Self‑Invocation Pitfalls

In a recent work project the author investigated Spring's @Transactional annotation to better control transaction boundaries and share practical insights for developers.

Transaction propagation behaviors are defined in TransactionDefinition and include the following constants:

TransactionDefinition.PROPAGATION_REQUIRED : Join existing transaction or create a new one (default).

TransactionDefinition.PROPAGATION_REQUIRES_NEW : Always start a new transaction, suspending any existing one.

TransactionDefinition.PROPAGATION_SUPPORTS : Join if a transaction exists; otherwise execute non‑transactionally.

TransactionDefinition.PROPAGATION_NOT_SUPPORTED : Execute non‑transactionally and suspend any existing transaction.

TransactionDefinition.PROPAGATION_NEVER : Execute non‑transactionally and throw an exception if a transaction exists.

TransactionDefinition.PROPAGATION_MANDATORY : Join an existing transaction; throw an exception if none exists.

TransactionDefinition.PROPAGATION_NESTED : Execute within a nested transaction if a transaction exists; otherwise behaves like PROPAGATION_REQUIRED .

Rollback mechanism – Spring’s declarative transaction management rolls back on unchecked (runtime) exceptions. The transaction starts before the business method and commits or rolls back after the method returns, depending on whether a RuntimeException (or subclass) was thrown. If a try{}catch(Exception e){} block swallows the exception, you must re‑throw a RuntimeException inside the catch to trigger rollback.

Self‑invocation problem : When a method annotated with @Transactional calls another method of the same class via this.method2() , the call bypasses the Spring proxy, so the second method’s transaction annotation is ineffective. This is a frequent interview question.

Method visibility : Only public methods can be proxied for transaction management. Annotating non‑public methods does not cause errors but has no effect.

Using proxies to invoke internal methods : Enable proxy exposure with @EnableAspectJAutoProxy(exposeProxy = true) and obtain the current proxy via AopContext.currentProxy() . Calling the target method through this proxy ensures the transaction advice is applied.

Example controller and service code:

@RestController
public class TransactionalController {
    @Autowired
    private TransactionalService transactionalService;

    @PostMapping("transactionalTest")
    public void transacionalTest(){
        transactionalService.transactionalMethod();
    }
}

public interface TransactionalService {
    void transactionalMethod();
}

When transactionalMethod invokes other methods within the same service, use the proxy (or separate beans) to keep each method in its own transaction if required.

Key takeaways :

@Transactional guarantees a transaction per method; ensure you re‑throw a runtime exception in catch blocks to trigger rollback.

Methods must be public for the annotation to work.

Self‑invocation via this bypasses the proxy, so transaction advice is not applied.

Use AopContext.currentProxy() or separate beans with @EnableAspectJAutoProxy(exposeProxy = true) to invoke methods through the proxy and achieve the desired transaction semantics.