Understanding Spring's @Transactional Annotation and Its AOP Implementation
This article explains how Spring's @Transactional annotation works by leveraging AOP and dynamic proxies, walks through the bean post‑processor and advisor setup, and details the core TransactionInterceptor code that manages transaction boundaries during method execution.
@Transactional Annotation Overview
@Transactionalis Spring's declarative transaction management annotation that enables automatic transaction start, commit, or rollback through AOP without polluting business logic.
Spring AOP Implementation Guess
Spring defines a pointcut for methods annotated with @Transactional. During bean initialization, AnnotationAwareAspectJAutoProxyCreator creates a proxy for such beans via its postProcessAfterInstantiation method, injecting a BeanFactoryTransactionAttributeSourceAdvisor as the advisor.
The proxy intercepts method calls, builds an interceptor chain, and ultimately invokes DynamicAdvisedInterceptor#intercept, where the TransactionInterceptor is placed.
TransactionInterceptor – Final Transaction Manager
The TransactionInterceptor#invoke method obtains the target class, then calls invokeWithinTransaction to handle transaction demarcation.
@Override
public Object invoke(final MethodInvocation invocation) throws Throwable {
Class<?> targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);
return invokeWithinTransaction(invocation.getMethod(), targetClass, new InvocationCallback() {
@Override
public Object proceedWithInvocation() throws Throwable {
return invocation.proceed();
}
});
}Inside invokeWithinTransaction, Spring retrieves the TransactionAttribute, determines the appropriate PlatformTransactionManager, and creates a transaction if necessary. It then proceeds with the method invocation, handling exceptions to trigger rollback or commit accordingly.
protected Object invokeWithinTransaction(Method method, Class<?> targetClass, final InvocationCallback invocation) throws Throwable {
final TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
final PlatformTransactionManager tm = determineTransactionManager(txAttr);
final String joinpointIdentification = methodIdentification(method, targetClass);
if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
Object retVal = null;
try {
retVal = invocation.proceedWithInvocation();
} catch (Throwable ex) {
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
} finally {
cleanupTransactionInfo(txInfo);
}
commitTransactionAfterReturning(txInfo);
return retVal;
} else {
// CallbackPreferringPlatformTransactionManager path omitted for brevity
}
}The article concludes by summarizing the full flow, matching the initial hypothesis with the actual source code analysis.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Top Architect
Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
