1. 程式人生 > 實用技巧 >Spring系列.事務管理原理簡析

Spring系列.事務管理原理簡析

Spring的事務管理功能能讓我們非常簡單地進行事務管理。只需要進行簡單的兩步配置即可:

step1:開啟事務管理功能

@Configuration
//@EnableTransactionManagement註解有以下幾個屬性
//proxyTargetClass屬相:指定事務的AOP是通過JDK動態代理實現,還是CGLIB動態代理實現。true的話是CGLIB,false的話是JDK動態代理
// 需要注意的是這個屬性只有在AdviceMode設定成AdviceMode.PROXY的情況下才會生效,加入使用ASPECTJ這AOP框架的話,這個屬性就失效了。
// 另外,這個屬性的設定可能會影響其他需要動態代理的類。比如說將這個屬性設定成true,@Async註解的方法也會使用CGLIB生成代理類。
// 但是總的來說,這個屬性的設定不會造成什麼負面影響,畢竟JDK動態代理和CGLIB動態代理都能實現我們的需求 //mode屬性:Spring提供的AOP功能有兩種實現方式,一種是Spring自帶的AOP功能,主要靠JDK代理和CGLIB代理實現,另外一種是通過第三方框架ASPECTJ實現。這個選項
// 就是設定Spring用哪種方式提供AOP功能。AdviceMode.PROXY表示用Spring自帶的AOP功能,AdviceMode.ASPECTJ表示使用AdviceMode提供AOP功能。
// 需要注意的是Spring自帶的AOP功能不支援本地呼叫的代理功能,也就是說同一個類中的方法互相呼叫不會“觸發”代理方法。如果想讓自呼叫觸發代理,可以考慮使用ASPECTJ。 //order屬性:表示當一個連線點(方法)被切多次時(也就是說有多個Advice和連線點關聯),這些連線點的執行順序。
@EnableTransactionManagement
public class TxConfig {
}

step2:在需要事務管理的方法上新增@Transactional註解

@Override
@Transactional
public int saveSysUser(SysUser user) {
int i = sysUserMapper.insert(user);
return i;
}

整個使用流程就這麼簡單。這篇部落格就來簡單分析下Spring是怎麼實現事務管理的。

對事務管理進行AOP的過程

Spring的很多功能都是通過AOP功能實現的,事務管理也是。我們之前的

文章分析過Spring基礎AOP實現的原理。這邊再簡單提下Spring實現AOP的

原理:

Spring基礎的AOP功能的開關是@EnableAspectJAutoProxy,這個註解註冊了一個Bean——AnnotationAwareAspectJAutoProxyCreator,這個Bean才是實現AOP功能的關鍵。

這個Bean實現了InstantiationAwareBeanPostProcessor介面(這個介面是BeanPostProcessor的子介面)。熟悉Spring的讀者知道,實現BeanPostProcessor介面的Bean

會在其他Bean初始化之前初始,然後在其他Bean初始化的時候,BeanPostProcessor的實現會對這些Bean進行“加工處理”。

這邊AnnotationAwareAspectJAutoProxyCreator就承擔了加工處理類的角色。這個Bean在其他Bean初始化前後會判斷這個Bean中的方法是不是有對應的Advice,如果有的話就會

通過動態代理的方式生成動態代理類將通知織入進去。

我們發現開啟事務管理的方式和開啟AOP功能的方式很像,也是通過Enable註解開啟。所以很自然就猜想事務管理是不是也是通過BeanPostProcessor的方式實現的。帶著這個猜想去看下@EnableTransactionManagement註解。


@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(TransactionManagementConfigurationSelector.class)
public @interface EnableTransactionManagement { boolean proxyTargetClass() default false;
AdviceMode mode() default AdviceMode.PROXY;
int order() default Ordered.LOWEST_PRECEDENCE;
}

看到上面的程式碼,我們很自然的會去看TransactionManagementConfigurationSelector的程式碼。Spring有兩種方式提供AOP功能,一種是自帶的動態代理的功能,一種是

通過ASPECTJ的方式提供。這邊主要討論Spring自帶的AOP功能。

protected String[] selectImports(AdviceMode adviceMode) {
switch (adviceMode) {
//用代理的方式實現事務管理的AOP功能
case PROXY:
return new String[] {AutoProxyRegistrar.class.getName(),
ProxyTransactionManagementConfiguration.class.getName()};
case ASPECTJ:
return new String[] {determineTransactionAspectClass()};
default:
return null;
}
}

上面的程式碼中,我們主要關注PROXY這個case中的方法。這個case中註冊了兩個類:AutoProxyRegistrar和ProxyTransactionManagementConfiguration。

首先我們來看AutoProxyRegistrar這個類,層層點進入,我們發現這個類最終就是註冊了InfrastructureAdvisorAutoProxyCreator這個類。仔細看InfrastructureAdvisorAutoProxyCreator

這個類實現的介面的話,你會發現這個類也是BeanPostProcesser系列的類。看到這裡,我的直覺是事務管理的AOP過程和Spring基礎的AOP功能原理可能是一樣的。

再仔細看InfrastructureAdvisorAutoProxyCreator對BeanPostProcesser系列介面的實現,你會發現都是繼承的AbstractAutoProxyCreator。看到這個驗證了我之前的想法。

下面是Spring對事務管理進行AOP的過程,你會發現和基礎的AOP功能是一套程式碼。

@Override
public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
if (bean != null) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
if (this.earlyProxyReferences.remove(cacheKey) != bean) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
}
return bean;
} protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) {
return bean;
}
if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
return bean;
}
if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
} // Create proxy if we have advice.
// 程式碼1
// 這邊是獲取Advice和Advisor的具體程式碼
Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
if (specificInterceptors != DO_NOT_PROXY) {
this.advisedBeans.put(cacheKey, Boolean.TRUE);
//生成代理類
Object proxy = createProxy(
bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
this.proxyTypes.put(cacheKey, proxy.getClass());
return proxy;
} this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
}

再來看看ProxyTransactionManagementConfiguration做了些啥?點進原始碼你會發現這個類的功能很簡單,就是註冊了下面幾個事務管理相關的基礎Bean。

  • BeanFactoryTransactionAttributeSourceAdvisor;
  • TransactionAttributeSource;
  • TransactionInterceptor。

事務管理的生效過程

上面的章節中講了Spring是怎麼生成事務相關的AOP代理類的。這邊來講下Spring的事務管理是怎麼生效的——怎麼開啟事務,怎麼回滾事務,怎麼提交事務,Spring中的事務傳播

機制是怎麼生效的。

這塊的程式碼主要是在TransactionAspectSupport的invokeWithinTransaction方法中(不要問我是怎麼找到這段程式碼的...)。下面講下這個方法中的幾個關鍵點。


protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
final InvocationCallback invocation) throws Throwable { // If the transaction attribute is null, the method is non-transactional.
TransactionAttributeSource tas = getTransactionAttributeSource();
//獲取TransactionAttribute,這個類主要是@Transactional註解的配置資訊
final TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);
//確認事務管理器
final TransactionManager tm = determineTransactionManager(txAttr); if (this.reactiveAdapterRegistry != null && tm instanceof ReactiveTransactionManager) {
ReactiveTransactionSupport txSupport = this.transactionSupportCache.computeIfAbsent(method, key -> {
if (KotlinDetector.isKotlinType(method.getDeclaringClass()) && KotlinDelegate.isSuspend(method)) {
throw new TransactionUsageException(
"Unsupported annotated transaction on suspending function detected: " + method +
". Use TransactionalOperator.transactional extensions instead.");
}
ReactiveAdapter adapter = this.reactiveAdapterRegistry.getAdapter(method.getReturnType());
if (adapter == null) {
throw new IllegalStateException("Cannot apply reactive transaction to non-reactive return type: " +
method.getReturnType());
}
return new ReactiveTransactionSupport(adapter);
});
return txSupport.invokeWithinTransaction(
method, targetClass, invocation, txAttr, (ReactiveTransactionManager) tm);
} PlatformTransactionManager ptm = asPlatformTransactionManager(tm);
final String joinpointIdentification = methodIdentification(method, targetClass, txAttr); if (txAttr == null || !(ptm instanceof CallbackPreferringPlatformTransactionManager)) {
// Standard transaction demarcation with getTransaction and commit/rollback calls.
TransactionInfo txInfo = createTransactionIfNecessary(ptm, txAttr, joinpointIdentification); Object retVal;
try {
// This is an around advice: Invoke the next interceptor in the chain.
// This will normally result in a target object being invoked.
retVal = invocation.proceedWithInvocation();
}
catch (Throwable ex) {
// target invocation exception
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
cleanupTransactionInfo(txInfo);
} if (vavrPresent && VavrDelegate.isVavrTry(retVal)) {
// Set rollback-only in case of Vavr failure matching our rollback rules...
TransactionStatus status = txInfo.getTransactionStatus();
if (status != null && txAttr != null) {
retVal = VavrDelegate.evaluateTryFailure(retVal, txAttr, status);
}
} commitTransactionAfterReturning(txInfo);
return retVal;
}else {
final ThrowableHolder throwableHolder = new ThrowableHolder(); // It's a CallbackPreferringPlatformTransactionManager: pass a TransactionCallback in.
try {
Object result = ((CallbackPreferringPlatformTransactionManager) ptm).execute(txAttr, status -> {
TransactionInfo txInfo = prepareTransactionInfo(ptm, txAttr, joinpointIdentification, status);
try {
Object retVal = invocation.proceedWithInvocation();
if (vavrPresent && VavrDelegate.isVavrTry(retVal)) {
// Set rollback-only in case of Vavr failure matching our rollback rules...
retVal = VavrDelegate.evaluateTryFailure(retVal, txAttr, status);
}
return retVal;
}
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.
throwableHolder.throwable = ex;
return null;
}
}
finally {
cleanupTransactionInfo(txInfo);
}
}); // Check result state: It might indicate a Throwable to rethrow.
if (throwableHolder.throwable != null) {
throw throwableHolder.throwable;
}
return result;
}
catch (ThrowableHolderException ex) {
throw ex.getCause();
}
catch (TransactionSystemException ex2) {
if (throwableHolder.throwable != null) {
logger.error("Application exception overridden by commit exception", throwableHolder.throwable);
ex2.initApplicationException(throwableHolder.throwable);
}
throw ex2;
}
catch (Throwable ex2) {
if (throwableHolder.throwable != null) {
logger.error("Application exception overridden by commit exception", throwableHolder.throwable);
}
throw ex2;
}
}
}

事務操作的主要程式碼都在這個方法中,要詳細將這個方法能寫很多內容。這邊就不詳細展開了,大家感興趣的可以仔細研究下這個方法。

重要類總結

  • InfrastructureAdvisorAutoProxyCreator:事務管理AOP註冊
  • BeanFactoryTransactionAttributeSourceAdvisor:Spring事務管理基礎Bean
  • TransactionAttributeSource:Spring事務管理基礎Bean
  • TransactionInterceptor:Spring事務管理基礎Bean
  • TransactionAspectSupport的invokeWithinTransaction方法:事務處理的主要方法