Spring Transaction Propagation: REQUIRED, REQUIRES_NEW, and the Common Pitfalls

Spring @Transactional has seven propagation modes but three that really matter. REQUIRED is the default — if a transaction exists, join it; if not, start a new one. So calling a REQUIRED method from another REQUIRED method reuses the same transaction, and a rollback in the inner method rolls back the whole thing. REQUIRES_NEW suspends any existing transaction and starts a brand new one; the inner rollback only affects the inner work, and the outer can commit independently. Use this for things like audit logs that must persist even if the business operation fails. NESTED uses a savepoint inside the outer transaction — inner rollback rolls back to the savepoint without killing the outer. Four common pitfalls. First, the default rollback rule only fires on RuntimeException and Error. If you throw a checked IOException, Spring commits the transaction. Fix: @Transactional(rollbackFor = Exception.class). Second, self-invocation — this.methodB() from within methodA() of the same class bypasses the Spring proxy, so @Transactional on methodB is never triggered. Fix: inject the bean into itself, use AopContext.currentProxy(), or restructure. Third, private methods — Spring AOP is subclass-based (CGLIB) or interface-based (JDK), neither can intercept private methods, so @Transactional on private is silently ignored. Fourth, catching the exception inside the method. If your code try/catches the DB exception and doesn't rethrow, Spring sees no exception and commits. The fix is either rethrow or explicitly call TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(). In production I treat @Transactional as "marks a method as needing a transaction — now verify the proxy path, the exception will propagate, and no self-calls."