Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is the principle of @ Transactional implementation of spring source code". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the principle of @ Transactional implementation of spring source code".

Catalogue

Introduction to @ Transactional annotations

Conjecture on the principle of declarative transaction implementation in spring

@ Transactional effect

Dynamic agent logic implementation

TransactionInterceptor- final transaction Manager

Summary

Introduction to @ Transactional annotations

@ Transactional is a way to configure annotations for declarative transaction management in spring, and I believe the role of this annotation is well known.

The @ Transactional annotation can help us manage the operation of opening, committing or rolling back transactions through aop.

The @ Transactional annotation allows spring to manage transactions for us, eliminating repetitive transaction management logic, reducing intrusions into business code, and enabling us developers to focus on business-level development.

We know that the implementation of @ Transactional principle is based on spring aop,aop and dynamic proxy mode. By reading the source code, we summarize the following steps to understand how spring uses aop to achieve the function of @ Transactional in practice. If you don't understand the aop implementation principle of spring, you can take a look at the aop implementation principle analysis.

Conjecture on the principle of declarative transaction implementation in spring

First of all, if you have any knowledge of the principle of aop implementation in spring, you should know that if you want to proxy a method, you definitely need to define pointcuts. Similarly, in the implementation of @ Transactional, spring defines a pointcut with the @ Transactional annotation as the planting point, so that we know that the method of the @ Transactional annotation needs to be proxied.

With the aspect definition in place, during the initialization of spring's bean, you need to proxy the instantiated bean and generate a proxy object.

In the proxy logic for generating proxy objects, you need to obtain the aspect logic first when you call a method. The aspect logic of @ Transactional annotation is similar to @ Around, which is similar to proxy logic in spring.

@ Transactional effect

According to the above principle guess, the following is a brief introduction of each step of the source code for verification.

The first is @ Transactional, which defines the agent planting point. In [Analysis of the principle of aop implementation], it is known that the proxy object is created through the postProcessAfterInstantiation method of the BeanPostProcessor implementation class AnnotationAwareAspectJAutoProxyCreator. If a proxy is needed, a proxy object is returned to the container in this method, and the planting point is also determined in this method.

Then let's start with the analysis. After configuring annotation-driven transaction management, spring will create an BeanFactoryTransactionAttributeSourceAdvisor instance in the ioc container, which can be regarded as a pointcut. To determine whether a bean needs to create a proxy object during initialization, you need to verify whether BeanFactoryTransactionAttributeSourceAdvisor is suitable for this bean. If so, you need to create a proxy object and inject a BeanFactoryTransactionAttributeSourceAdvisor instance into the proxy object.

Among them, [aop implementation principle Analysis] knows whether the aspect is suitable for the current bean in AopUtils#findAdvisorsThatCanApply, you can analyze the call stack at this place, AopUtils#findAdvisorsThatCanApply calls consistently, and finally determine whether the pointcut is applicable through the following code.

AbstractFallbackTransactionAttributeSource#computeTransactionAttribute (Method method, Class targetClass)

Here, you can debug and analyze the call stack with conditional breakpoints according to the parameters, and targetClass is the target class.

... A series of calls end up

SpringTransactionAnnotationParser#parseTransactionAnnotation (java.lang.reflect.AnnotatedElement) @ Overridepublic TransactionAttribute parseTransactionAnnotation (AnnotatedElement ae) {/ / this is to analyze whether Method is annotated by @ Transactional, if so, not to mention that BeanFactoryTransactionAttributeSourceAdvisor adapts to the current bean, acts as a proxy, and injects the pointcut / / BeanFactoryTransactionAttributeSourceAdvisor AnnotationAttributes attributes = AnnotatedElementUtils.getMergedAnnotationAttributes (ae, Transactional.class); if (attributes! = null) {return parseTransactionAnnotation (attributes);} else {return null;}}

This is the process of determining whether a proxy object needs to be created according to @ Transactional. One of the functions of @ Transactional is to identify that the method needs to be proxied, and the other is to carry some attribute information needed for transaction management.

Dynamic agent logic implementation

[analysis of the principle of aop implementation] it is known that the proxy method of the final proxy object of aop is

DynamicAdvisedInterceptor#intercept

So we can analyze the agent logic at this method breakpoint.

Overridepublic Object intercept (Object proxy, Method method, Object [] args, MethodProxy methodProxy) throws Throwable {Object oldProxy = null; boolean setProxyContext = false; Class targetClass = null; Object target = null; try {if (this.advised.exposeProxy) {/ / Make invocation available if necessary. OldProxy = AopContext.setCurrentProxy (proxy); setProxyContext = true;} / / May be null. Get as late as possible to minimize the time we / / "own" the target, in case it comes from a pool... Target = getTarget (); if (target! = null) {targetClass = target.getClass ();} / follow List chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice (method, targetClass); Object retVal; / / Check whether we only have one InvokerInterceptor: that is, / / no real advice, but just reflective invocation of the target. If (chain.isEmpty () & Modifier.isPublic (method.getModifiers () {/ / We can skip creating a MethodInvocation: just invoke the target directly. / / Note that the final invoker must be an InvokerInterceptor, so we know / / it does nothing but a reflective operation on the target, and no hot / / swapping or fancy proxying. Object [] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary (method, args); retVal = methodProxy.invoke (target, argsToUse);} else {/ / We need to create a method invocation... RetVal = new CglibMethodInvocation (proxy, target, method, args, targetClass, chain, methodProxy). Proceed ();} retVal = processReturnType (proxy, target, method, retVal); return retVal;} finally {if (target! = null) {releaseTarget (target);} if (setProxyContext) {/ / Restore old proxy. AopContext.setCurrentProxy (oldProxy);}

Through analysis

List chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice (method, targetClass)

What is returned is TransactionInterceptor. How to implement the proxy logic call using TransactionInterceptor? Tracking

New CglibMethodInvocation (proxy, target, method, args, targetClass, chain, methodProxy). Proceed ()

It is found that the TransactionInterceptor#invoke method is finally called and CglibMethodInvocation is injected into the invoke method. From the above, you can see that CglibMethodInvocation wraps all the necessary information for the method call of the target object. Therefore, the target method can also be called in TransactionInterceptor#invoke, and you can also implement logic similar to @ Around, and continue to inject some other logic, such as transaction management logic, before and after the target method call.

TransactionInterceptor- final transaction Manager

Let's look at the code.

TransactionInterceptor#invoke@Overridepublic Object invoke (final MethodInvocation invocation) throws Throwable {/ / Work out the target class: may be {@ code null}. / / The TransactionAttributeSource should be passed the target class / / as well as the method, which may be from an interface. Class targetClass = (invocation.getThis ()! = null? AopUtils.getTargetClass (invocation.getThis ()): null); / / Adapt to TransactionAspectSupport's invokeWithinTransaction... Return invokeWithinTransaction (invocation.getMethod (), targetClass, new InvocationCallback () {@ Override public Object proceedWithInvocation () throws Throwable {return invocation.proceed ();}});}

Continue to track invokeWithinTransaction, the following code can actually see some logical clues, that is, the implementation of our guess, transaction management.

Protected Object invokeWithinTransaction (Method method, Class targetClass, final InvocationCallback invocation) throws Throwable {/ / If the transaction attribute is null, the method is non-transactional. Final TransactionAttribute txAttr = getTransactionAttributeSource (). GetTransactionAttribute (method, targetClass); final PlatformTransactionManager tm = determineTransactionManager (txAttr); final String joinpointIdentification = methodIdentification (method, targetClass); if (txAttr = = null | |! (tm instanceof CallbackPreferringPlatformTransactionManager)) {/ / Standard transaction demarcation with getTransaction and commit/rollback calls. / / Open transaction TransactionInfo txInfo = createTransactionIfNecessary (tm, txAttr, joinpointIdentification); Object retVal = null; try {/ / This is an around advice: Invoke the next interceptor in the chain. / / This will normally result in a target object being invoked. / / method call retVal = invocation.proceedWithInvocation ();} catch (Throwable ex) {/ / target invocation exception / / rollback transaction completeTransactionAfterThrowing (txInfo, ex); throw ex;} finally {cleanupTransactionInfo (txInfo);} / / commit transaction commitTransactionAfterReturning (txInfo); return retVal } else {/ / It's a CallbackPreferringPlatformTransactionManager: pass a TransactionCallback in. Try {Object result = ((CallbackPreferringPlatformTransactionManager) tm) .execute (txAttr, new TransactionCallback () {@ Override public Object doInTransaction (TransactionStatus status) {TransactionInfo txInfo = prepareTransactionInfo (tm, txAttr, joinpointIdentification, status); try {return invocation.proceedWithInvocation () } catch (Throwable ex) {if (txAttr.rollbackOn (ex)) {/ / A RuntimeException: will lead to a rollback. If (ex instanceof RuntimeException) {throw (RuntimeException) ex;} else {throw new ThrowableHolderException (ex) }} else {/ / A normal return value: will lead to a commit. Return new ThrowableHolder (ex);}} finally {cleanupTransactionInfo (txInfo);}); / / Check result: It might indicate a Throwable to rethrow. If (result instanceof ThrowableHolder) {throw ((ThrowableHolder) result). GetThrowable ();} else {return result;}} catch (ThrowableHolderException ex) {throw ex.getCause ();} Summary

Finally, you can summarize the whole process and compare it with the initial conjecture.

Analysis of source code post-control

Thank you for reading, the above is "what is the principle of @ Transactional implementation of spring source code". After the study of this article, I believe you have a deeper understanding of what the principle of @ Transactional implementation of spring source code is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.