Spring事务以及声明事务失效的几种原因

Spring事务以及声明事务失效的几种原因

429 次访问
· 默认分类

一、Spring事务管理的几种方式

1.声明式

  • 基于 TransactionProxyFactoryBean的声明式事务管理
  • 基于 <tx> 和 <aop> 命名空间的事务管理
  • 基于 @Transactional 的声明式事务管理

注:

@Transactional源码分析参考 https://blog.csdn.net/acingdreamer/article/details/91873745

2.编程式

  • 基于事务管理器API 的编程式事务管理
  • 基于TransactionTemplate 的编程式事务管理

注:目前大部分项目使用的是声明式的后两种：

  • 基于 <tx> 和 <aop> 命名空间的声明式事务管理可以充分利用切点表达式的强大支持，使得管理事务更加灵活。
  • 基于 @Transactional 的方式需要实施事务管理的方法或者类上使用 @Transactional 指定事务规则即可实现事务管理，在Spring Boot中通常也建议使用这种注解方式来标记事务。

二、Spring事务基本原理

Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。对于纯JDBC操作数据库，想要用到事务，可以按照以下步骤进行：

1.获取连接 Connection con = DriverManager.getConnection()

2.开启事务con.setAutoCommit(true/false);

3.执行CRUD

4.提交事务/回滚事务 con.commit() / con.rollback();

5.关闭连接 conn.close();

使用Spring的事务管理功能后，我们可以不再写步骤 2 和 4 的代码，而是由Spirng 自动完成。那么Spring是如何在我们书写的 CRUD 之前和之后开启事务和关闭事务的呢？解决这个问题，也就可以从整体上理解Spring的事务管理实现原理了。

下面简单地介绍下，注解方式为例子

1.配置文件开启注解驱动，在相关的类和方法上通过注解@Transactional标识。

2.spring 在启动的时候会去解析生成相关的bean，这时候会查看拥有相关注解的类和方法，并且为这些类和方法生成代理，并根据@Transaction的相关参数进行相关配置注入，这样就在代理中为我们把相关的事务处理掉了（开启正常提交事务，异常回滚事务）。

3.真正的数据库层的事务提交和回滚是通过binlog或者redo log实现的。

三、Spring的事务机制

所有的数据访问技术都有事务处理机制，这些技术提供了API用来开启事务、提交事务来完成数据操作，或者在发生错误的时候回滚数据。

而Spring的事务机制是用统一的机制来处理不同数据访问技术的事务处理。Spring的事务机制提供了一个PlatformTransactionManager接口，不同的数据访问技术的事务使用不同的接口实现，如表所示。

数据访问技术及实现

image-20210330190813446

在程序中定义事务管理器的代码如下：

@Bean   
public PlatformTransactionManager transactionManager() {    
 JpaTransactionManager transactionManager = new JpaTransactionManager();   
 transactionManager.setDataSource(dataSource());   
 return transactionManager;   
}

四、AOP 代理的两种实现：

  • jdk是代理接口，私有方法必然不会存在在接口里，所以就不会被拦截到；
  • cglib是子类，private的方法照样不会出现在子类里，也不能被拦截。

详细参考:https://mp.weixin.qq.com/s/qb8j4qELdnCCsUIpB_iwGg

4.1.Java 动态代理

具体有如下四步骤：

  1. 通过实现 InvocationHandler 接口创建自己的调用处理器；
  2. 通过为 Proxy 类指定 ClassLoader 对象和一组 interface 来创建动态代理类；
  3. 通过反射机制获得动态代理类的构造函数，其唯一参数类型是调用处理器接口类型；
  4. 通过构造函数创建动态代理类实例，构造时调用处理器对象作为参数被传入。

4.2.GCLIB代理

cglib（Code Generation Library）是一个强大的,高性能,高质量的Code生成类库。它可以在运行期扩展Java类与实现Java接口。

  • cglib封装了asm，可以在运行期动态生成新的class（子类）。
  • cglib用于AOP，jdk中的proxy必须基于接口，cglib却没有这个限制。

4.3.原理区别：

java动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler来处理。而cglib动态代理是利用asm开源包，对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理。

  1. 如果目标对象实现了接口，默认情况下会采用JDK的动态代理实现AOP
  2. 如果目标对象实现了接口，可以强制使用CGLIB实现AOP
  3. 如果目标对象没有实现了接口，必须采用CGLIB库，spring会自动在JDK动态代理和CGLIB之间转换

五、Spring 事务的传播属性

所谓spring事务的传播属性，就是定义在存在多个事务同时存在的时候，spring应该如何处理这些事务的行为。这些属性在TransactionDefinition中定义，具体常量的解释见下表：

image-20210330191355257

Spring中的隔离级别

image-20210330191508165

事务的嵌套

通过上面的理论知识的铺垫，我们大致知道了数据库事务和spring事务的一些属性和特点，接下来我们通过分析一些嵌套事务的场景，来深入理解spring事务传播的机制。

假设外层事务 Service A 的 Method A() 调用 内层Service B 的 Method B()

==PROPAGATION_REQUIRED(spring 默认)==

如果ServiceB.methodB() 的事务级别定义为 PROPAGATION_REQUIRED，那么执行 ServiceA.methodA() 的时候spring已经起了事务，这时调用 ServiceB.methodB()，ServiceB.methodB() 看到自己已经运行在 ServiceA.methodA() 的事务内部，就不再起新的事务。

假如 ServiceB.methodB() 运行的时候发现自己没有在事务中，他就会为自己分配一个事务。

这样，在 ServiceA.methodA() 或者在 ServiceB.methodB() 内的任何地方出现异常，事务都会被回滚。

==PROPAGATION_REQUIRES_NEW==

比如我们设计 ServiceA.methodA() 的事务级别为 PROPAGATION_REQUIRED，ServiceB.methodB() 的事务级别为 PROPAGATION_REQUIRES_NEW。

那么当执行到 ServiceB.methodB() 的时候，ServiceA.methodA() 所在的事务就会挂起，ServiceB.methodB() 会起一个新的事务，等待 ServiceB.methodB() 的事务完成以后，它才继续执行。

他与 PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为 ServiceB.methodB() 是新起一个事务，那么就是存在两个不同的事务。如果 ServiceB.methodB() 已经提交，那么 ServiceA.methodA() 失败回滚，ServiceB.methodB() 是不会回滚的。如果 ServiceB.methodB() 失败回滚，如果他抛出的异常被 ServiceA.methodA() 捕获，ServiceA.methodA() 事务仍然可能提交(主要看B抛出的异常是不是A会回滚的异常)。

==PROPAGATION_SUPPORTS==

假设ServiceB.methodB() 的事务级别为 PROPAGATION_SUPPORTS，那么当执行到ServiceB.methodB()时，如果发现ServiceA.methodA()已经开启了一个事务，则加入当前的事务，如果发现ServiceA.methodA()没有开启事务，则自己也不开启事务。这种时候，内部方法的事务性完全依赖于最外层的事务。

==PROPAGATION_NESTED==

现在的情况就变得比较复杂了, ServiceB.methodB() 的事务属性被配置为 PROPAGATION_NESTED, 此时两者之间又将如何协作呢? ServiceB#methodB 如果 rollback, 那么内部事务(即 ServiceB#methodB) 将回滚到它执行前的 SavePoint 而外部事务(即 ServiceA#methodA) 可以有以下两种处理方式:

a、捕获异常，执行异常分支逻辑

void methodA() {   
  
        try {   
  
            ServiceB.methodB();   
  
        } catch (SomeException) {   
  
            // 执行其他业务, 如 ServiceC.methodC();   
  
        }   
  
    }

这种方式也是嵌套事务最有价值的地方, 它起到了分支执行的效果, 如果 ServiceB.methodB 失败, 那么执行 ServiceC.methodC(), 而 ServiceB.methodB 已经回滚到它执行之前的 SavePoint, 所以不会产生脏数据(相当于此方法从未执行过), 这种特性可以用在某些特殊的业务中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都没有办法做到这一点。

b、 外部事务回滚/提交 代码不做任何修改, 那么如果内部事务(ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滚到它执行之前的 SavePoint(在任何情况下都会如此), 外部事务(即 ServiceA#methodA) 将根据具体的配置决定自己是 commit 还是 rollback

六、声明事务失效的几个原因

  • @Transactional注解的各项参数
public @interface Transactional {
    @AliasFor("transactionManager")
    String value() default "";

    @AliasFor("value")
    String transactionManager() default "";

    Propagation propagation() default Propagation.REQUIRED;

    Isolation isolation() default Isolation.DEFAULT;

    int timeout() default -1;

    boolean readOnly() default false;

    Class<? extends Throwable>[] rollbackFor() default {};

    String[] rollbackForClassName() default {};

    Class<? extends Throwable>[] noRollbackFor() default {};

    String[] noRollbackForClassName() default {};
}

  • timtout

    timtout是用来设置事务的超时时间，可以看到默认为-1，不会超时。

  • isolation

    isolation属性是用来设置事务的隔离级别，数据库有四种隔离级别：读未提交、读已提交、可重复读、可串行化。MySQL的默认隔离级别是可重复读。

public enum Isolation {
    DEFAULT(-1),
    READ_UNCOMMITTED(1),  // 读未提交
    READ_COMMITTED(2), 		// 读已提交
    REPEATABLE_READ(4), 	// 可重复读
    SERIALIZABLE(8);			// 可串行化
}
  • readOnly

readOnly属性用来设置该属性是否是只读事务，只读事务要从两方面来理解：它的功能是设置了只读事务后在整个事务的过程中，其他事务提交的内容对当前事务是不可见的。

那为什么要设置只读事务呢？它的好处是什么？可以看出它的作用是保持整个事务的数据一致性，如果事务中有多次查询，不会出现数据不一致的情况。所以在一个事务中如果有多次查询，可以启用只读事务，如果只有一次查询就无需只读事务了。

另外，使用了只读事务，数据库会提供一些优化。

但要注意的是，只读事务中只能有读操作，不能含有写操作，否则会报错。

  • propagation

propagation属性用来设置事务的传播行为，对传播行为的理解，可以参考如下场景，一个开启了事务的方法A，调用了另一个开启了事务的方法B，此时会出现什么情况？这就要看传播行为的设置了。

public enum Propagation {
    REQUIRED(0), 				// 如果有事务则加入，没有则新建
    SUPPORTS(1),				// 如果已有事务就用，如果没有就不开启(继承关系)
    MANDATORY(2),				// 必须在已有事务中
    REQUIRES_NEW(3),		// 不管是否已有事务，都要开启新事务，老事务挂起
    NOT_SUPPORTED(4),   // 不开启事务
    NEVER(5),						// 必须在没有事务的方法中调用，否则抛出异常
    NESTED(6);					// 如果已有事务，则嵌套执行，如果没有，就新建(和REQUIRED类似，和REQUIRES_NEW容易混淆)
}

REQUIRES_NEW 和 NESTED非常容易混淆，因为它们都是开启了一个新的事务。我去查询了一下它们之间的区别，大概是这样：

REQUIRES_NEW是开启一个完全的全新事务，和当前事务没有任何关系，可以单独地失败、回滚、提交。并不依赖外部事务。在新事务执行过程中，老事务是挂起的。

NESTED也是开启新事务，但它开启的是基于当前事务的子事务，如果失败的话单独回滚，但如果成功的话，并不会立即commit，而是等待外部事务的执行结果，外部事务commit时，子事务才会commit。

  • rollbackFor

在@Transactional注解中，有一个重要属性是roolbackFor，这是用来判断在什么异常下会进行回滚的，当方法内抛出指定的异常时，进行事务回滚。rollbackForClassName也是类似的。

rollbackFor有个问题是默认情况会做什么，以前认为默认会对所有异常进行回滚，但其实默认情况下只对RuntimeException回滚。

  • noRollbackFor

这个和上面正好相反，用来设置出现指定的异常时，不进行回滚。

声明式事务的实现机制

Spring在调用事务增强器的代理类时会首先执行TransactionInterceptor进行增强，在TransactionInterceptor的invoke方法中完成事务逻辑。首先看下TransactionInterceptor的类图结构。

image-20210331141431841

TransactionInterceptor

public Object invoke(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,invocation::proceed);
	}

在invoke方法里，调用了父类的模板方法invokeWithinTransaction，下面我们看下TransactionAspectSupport类。

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();
		final TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);
  	// 获取PlatformTransactionManager的实现类，底层事务的处理实现都是由PlatformTransactionManager的实现类实现的，比如 DataSourceTransactionManager 管理 JDBC 的 Connection。
		final PlatformTransactionManager tm = determineTransactionManager(txAttr);
  	// 切点标识
		final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);

		if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
			// Standard transaction demarcation with getTransaction and commit/rollback calls.
      // 这里是根据事务的传播行为属性去判断是否创建一个事务
			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.
        // around增强，这里是执行的回调的目标方法
				retVal = invocation.proceedWithInvocation();
			}
			catch (Throwable ex) {
				// target invocation exception
        // 异常回滚
				completeTransactionAfterThrowing(txInfo, ex);
				throw ex;
			}
			finally {
        // 清理信息
				cleanupTransactionInfo(txInfo);
			}
      // 提交事务
			commitTransactionAfterReturning(txInfo);
			return retVal;
		}

		else {
			final ThrowableHolder throwableHolder = new ThrowableHolder();

			// It's a CallbackPreferringPlatformTransactionManager: pass a TransactionCallback in.
			try {
				Object result = ((CallbackPreferringPlatformTransactionManager) tm).execute(txAttr, 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.
							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;
			}
		}
	}

createTransactionIfNecessary

可以看到，这个invokeWithinTransaction方法已经包含了事务执行的整个流程，这里是使用了模板模式，具体的实现交给子类去实现。下面我们分析一下其中的重要方法。

protected TransactionInfo createTransactionIfNecessary(@Nullable PlatformTransactionManager tm,
			@Nullable TransactionAttribute txAttr, final String joinpointIdentification) {

		// If no name specified, apply method identification as transaction name.
		if (txAttr != null && txAttr.getName() == null) {
			txAttr = new DelegatingTransactionAttribute(txAttr) {
				@Override
				public String getName() {
					return joinpointIdentification;
				}
			};
		}

		TransactionStatus status = null;
		if (txAttr != null) {
			if (tm != null) {
        // 获取事务状态，判断各种属性
				status = tm.getTransaction(txAttr);
			}
			else {
				if (logger.isDebugEnabled()) {
					logger.debug("Skipping transactional joinpoint [" + joinpointIdentification +
							"] because no transaction manager has been configured");
				}
			}
		}
  	// 返回一个TransactionInfo
		return prepareTransactionInfo(tm, txAttr, joinpointIdentification, status);
	}

1.数据库引擎不支持事务

这里以 MySQL 为例，其 MyISAM 引擎是不支持事务操作的，InnoDB 才是支持事务的引擎，一般要支持事务都会使用 InnoDB。

从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM，所以这点要值得注意，底层引擎不支持事务再怎么搞都是白搭。

2.没有被 Spring 管理

如下面例子所示：
// @Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void updateOrder(Order order) {
        // update order
    }

}

如果此时把 @Service 注解注释掉，这个类就不会被加载成一个 Bean，那这个类就不会被 Spring 管理了，事务自然就失效了。

3.方法不是 public 的

以下来自 Spring 官方文档：

When using proxies, you should apply the @Transactional annotation only to methods with public visibility. If you do annotate protected, private or package-visible methods with the @Transactional annotation, no error is raised, but the annotated method does not exhibit the configured transactional settings. Consider the use of AspectJ (see below) if you need to annotate non-public methods.

大概意思就是 @Transactional 只能用于 public 的方法上，否则事务不会失效，如果要用在非 public 方法上，可以开启 AspectJ 代理模式。

原因分析：

@Transactional注解标注方法修饰符为非public时，@Transactional注解将会不起作用。这里分析 的原因是，@Transactional是基于动态代理实现的，@Transactional注解实现原理中分析了实现方法，在bean初始化过程中，对含有@Transactional标注的bean实例创建代理对象，这里就存在一个spring扫描@Transactional注解信息的过程，不幸的是源码中体现，标注@Transactional的方法如果修饰符不是public，那么就默认方法的@Transactional信息为空，那么将不会对bean进行代理对象创建或者不会对方法进行代理调用

@Transactional注解实现原理中，介绍了如何判定一个bean是否创建代理对象，大概逻辑是。根据spring创建好一个aop切点BeanFactoryTransactionAttributeSourceAdvisor实例，遍历当前bean的class的方法对象，判断方法上面的注解信息是否包含@Transactional，如果bean任何一个方法包含@Transactional注解信息，那么就是适配这个BeanFactoryTransactionAttributeSourceAdvisor切点。则需要创建代理对象，然后代理逻辑为我们管理事务开闭逻辑。

spring源码中，在拦截bean的创建过程，寻找bean适配的切点时，运用到下面的方法，目的就是寻找方法上面的@Transactional信息，如果有，就表示切点BeanFactoryTransactionAttributeSourceAdvisor能够应用（canApply）到bean中，

  • AopUtils#canApply(org.springframework.aop.Pointcut, java.lang.Class<?>, boolean)
public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {
   Assert.notNull(pc, "Pointcut must not be null");
   if (!pc.getClassFilter().matches(targetClass)) {
      return false;
   }

   MethodMatcher methodMatcher = pc.getMethodMatcher();
   if (methodMatcher == MethodMatcher.TRUE) {
      // No need to iterate the methods if we're matching any method anyway...
      return true;
   }

   IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;
   if (methodMatcher instanceof IntroductionAwareMethodMatcher) {
      introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;
   }

    //遍历class的方法对象
   Set<Class<?>> classes = new LinkedHashSet<Class<?>>(ClassUtils.getAllInterfacesForClassAsSet(targetClass));
   classes.add(targetClass);
   for (Class<?> clazz : classes) {
      Method[] methods = ReflectionUtils.getAllDeclaredMethods(clazz);
      for (Method method : methods) {
         if ((introductionAwareMethodMatcher != null &&
               introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions)) ||
             //适配查询方法上的@Transactional注解信息  
             methodMatcher.matches(method, targetClass)) {
            return true;
         }
      }
   }

   return false;
}

我们可以在上面的方法打断点，一步一步调试跟踪代码，最终上面的代码还会调用如下方法来判断。在下面的方法上断点，回头看看方法调用堆栈也是不错的方式跟踪

  • AbstractFallbackTransactionAttributeSource#computeTransactionAttribute
protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) {
   // Don't allow no-public methods as required.
   //非public 方法，返回@Transactional信息一律是null
   if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
      return null;
   }
   //后面省略.......
 }

不创建代理对象

所以，如果所有方法上的修饰符都是非public的时候，那么将不会创建代理对象。以一开始的测试代码为例，如果正常的修饰符的testService是下面图片中的，经过cglib创建的代理对象。

image-20210330195301225

如果class中的方法都是非public的那么将不是代理对象。

image-20210330195330785

不进行代理调用

考虑一种情况，如下面代码所示。两个方法都被@Transactional注解标注，但是一个有public修饰符一个没有，那么这种情况我们可以预见的话，一定会创建代理对象，因为至少有一个public修饰符的@Transactional注解标注方法。

创建了代理对象，insertTestWrongModifier就会开启事务吗？答案是不会。

/**
 * @author zhoujy
 **/
@Component
public class TestServiceImpl implements TestService {
    @Resource
    TestMapper testMapper;

    @Override
    @Transactional
    public void insertTest() {
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }
    
    @Transactional
    void insertTestWrongModifier() {
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }
}

4.自身调用问题

@Service
public class OrderServiceImpl implements OrderService {

    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional
    public void updateOrder(Order order) {
        // update order
    }

}

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void updateOrder(Order order) {
        // update order
    }

}

update方法上面没有加 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？

这次在 update 方法上加了 @Transactional，updateOrder 加了 REQUIRES_NEW 新开启一个事务，那么新开的事务管用么？

这两个例子的答案是：不管用！

因为它们发生了自身调用，就调该类自己的方法，而没有经过 Spring 的代理类，默认只有在外部调用事务才会生效，这也是老生常谈的经典问题了。

既然事务管理是基于动态代理对象的代理逻辑实现的，那么如果在类内部调用类内部的事务方法，这个调用事务方法的过程并不是通过代理对象来调用的，而是直接通过this对象来调用方法，绕过的代理对象，肯定就是没有代理逻辑了。

其实我们可以这样玩，内部调用也能实现开启事务，代码如下。

/**
 * @author zhoujy
 **/
@Component
public class TestServiceImpl implements TestService {
    @Resource
    TestMapper testMapper;

    @Resource
    TestServiceImpl testServiceImpl;


    @Transactional
    public void insertTestInnerInvoke() {
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }


    public void testInnerInvoke(){
        //内部调用事务方法
        testServiceImpl.insertTestInnerInvoke();
    }

}

上面就是使用了代理对象进行事务调用，所以能够开启事务管理，但是实际操作中，没人会闲的蛋疼这样子玩~

参考：

https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw==&mid=2247491775&idx=2&sn=142f1d6ab0415f17a413a852efbde54f&scene=21#wechat_redirect

5.数据源没有配置事务管理器

@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

如上面所示，当前数据源若没有配置事务管理器，那也是白搭！

6.不支持事务

来看下面这个例子：

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    public void updateOrder(Order order) {
        // update order
    }

}

Propagation.NOT_SUPPORTED： 表示不以事务运行，当前若存在事务则挂起，详细的可以参考《事务隔离级别和传播机制》这篇文章。

都主动不支持以事务方式运行了，那事务生效也是白搭！

7.异常被吃了

这个也是出现比较多的场景：

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void updateOrder(Order order) {
        try {
            // update order
        } catch {

        }
    }

}

事务方法内部捕捉了异常，没有抛出新的异常，导致事务操作不会进行回滚

这种的话，可能我们比较常见，问题就出在代理逻辑中，我们先看看源码里卖弄动态代理逻辑是如何为我们管理事务的。

  • TransactionAspectSupport#invokeWithinTransaction

代码如下。

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.
       //开启事务
      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.
          //反射调用业务方法
         retVal = invocation.proceedWithInvocation();
      }
      catch (Throwable ex) {
         // target invocation exception
          //异常时，在catch逻辑中回滚事务
         completeTransactionAfterThrowing(txInfo, ex);
         throw ex;
      }
      finally {
         cleanupTransactionInfo(txInfo);
      }
       //提交事务
      commitTransactionAfterReturning(txInfo);
      return retVal;
   }

   else {
     //....................
   }
}

所以看了上面的代码就一目了然了，事务想要回滚，必须能够在这里捕捉到异常才行，如果异常中途被捕捉掉，那么事务将不会回滚。

8.异常类型错误

上面的例子再抛出一个异常：

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void updateOrder(Order order) {
        try {
            // update order
        } catch {
            throw new Exception("更新错误");
        }
    }
}

这样事务也是不生效的，因为默认回滚的是：RuntimeException，如果你想触发其他异常的回滚，需要在注解上配置一下，如：

@Transactional(rollbackFor = Exception.class)

这个配置仅限于 Throwable 异常类及其子类。

rollbackFor 可以指定能够触发事务回滚的异常类型。Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定rollbackFor属性。

image-20210330202444674

// 希望自定义的异常可以进行回滚
@Transactional(propagation= Propagation.REQUIRED,rollbackFor= MyException.class

若在目标方法中抛出的异常是 rollbackFor 指定的异常的子类，事务同样会回滚。Spring源码如下：

private int getDepth(Class<?> exceptionClass, int depth) {
        if (exceptionClass.getName().contains(this.exceptionName)) {
            // Found it!
            return depth;
		}
        // If we've gone as far as we can go and haven't found it...
        if (exceptionClass == Throwable.class) {
            return -1;
		}
		return getDepth(exceptionClass.getSuperclass(), depth + 1);
}

public boolean rollbackOn(Throwable ex) {
		return (ex instanceof RuntimeException || ex instanceof Error);
	}

9.多线程下事务管理

多线程下事务管理因为线程不属于 spring 托管，故线程不能够默认使用 spring 的事务,也不能获取spring 注入的 bean 。

在被 spring 声明式事务管理的方法内开启多线程，多线程内的方法不被事务控制。 一个使用了@Transactional 的方法，如果方法内包含多线程的使用，方法内部出现异常， 不会回滚线程中调用方法的事务。

如下代码，线程内调用insert方法，spring不会把insert方法加入事务，就算在insert方法上加入@Transactional注解，也不起作用。

因为调用本类的方法，会让注解，还是AOP切面无法注切入（具体看事务管理实现源码）。调用别的类的话，然后就会有事务切入，然后就会有管理。

spring 的事务是通过LocalThread来保证线程安全的，事务和当前线程绑定， 搞了多个线程自然会让事务失效。

Spring 就是使用ThreadLocal来存储Connection的，不同的线程Connection肯定不一样，所以不可能会在同一个事务中。

@Service  
public class ServiceA {  
   
    @Transactional  
    public void threadMethod(){  
        this.insert();  
         System.out.println("main insert is over");  
        for(int a=0 ;a<3;a++){  
            ThreadOperation threadOperation= new ThreadOperation();  
            Thread innerThread = new Thread(threadOperation);  
            innerThread.start();  
        }  
    }  
   
    public  class ThreadOperation implements Runnable {  
        public ThreadOperation(){  
        }  
        @Override  
        public void run(){  
            insert();  
            System.out.println("thread insert is over");  
        }  
    }  
   
    public void insert(){  
   
    //do insert......  
   
    }  
}

七、编程式事务

OrdersDao.java

import org.springframework.jdbc.core.JdbcTemplate;

public class OrdersDao {
	// 注入jdbcTemplate模板对象
	private JdbcTemplate jdbcTemplate;

	public void setJdbcTemplate(JdbcTemplate jdbcTemplate) {
		this.jdbcTemplate = jdbcTemplate;
	}

	// 对数据操作的方法不包含业务操作
	/**
	 * 小王少钱的方法
	 */
	public void reduceMoney() {
		String sql = "update account set salary=salary-? where username=?";
		jdbcTemplate.update(sql, 1000, "小王");
	}

	/**
	 * 小马多钱的方法
	 */
	public void addMoney() {
		String sql = "update account set salary=salary+? where username=?";
		jdbcTemplate.update(sql, 1000, "小马");
	}
}

OrdersService.java（业务逻辑层）

import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.TransactionCallback;
import org.springframework.transaction.support.TransactionTemplate;

import cn.itcast.dao.OrdersDao;

public class OrdersService {
	// 注入Dao层对象
	private OrdersDao ordersDao;

	public void setOrdersDao(OrdersDao ordersDao) {
		this.ordersDao = ordersDao;
	}

	// 注入TransactionTemplate对象
	private TransactionTemplate transactionTemplate;

	public void setTransactionTemplate(TransactionTemplate transactionTemplate) {
		this.transactionTemplate = transactionTemplate;
	}

	// 调用dao的方法
	// 业务逻辑，写转账业务
	public void accountMoney() {
		transactionTemplate.execute(new TransactionCallback<Object>() {

			@Override
			public Object doInTransaction(TransactionStatus status) {
				Object result = null;
				try {
					// 小马多1000
					ordersDao.addMoney();
					// 加入出现异常如下面int
					// i=10/0（银行中可能为突然停电等。。。）；结果：小马账户多了1000而小王账户没有少钱
					// 解决办法是出现异常后进行事务回滚
					int i = 10 / 0;// 事务管理配置后异常已经解决
					// 小王 少1000
					ordersDao.reduceMoney();
				} catch (Exception e) {
					status.setRollbackOnly();
					result = false;
					System.out.println("Transfer Error!");
				}

				return result;
			}
		});

	}
}

第二种写法：

基于底层Api

涉及到的接口对应的类型：
PlatformTransactionManager 事务管理器
TransactionDefinition 事务基础信息
TransactionStatus 事务状态信息

@Service
public class OrderServiceImpl implements OrderService {

    //Autowired自动注入的bean需要在spring配置文件中配置
    @Autowired
    private OrderDao orderDao;
    @Autowired
    private ProductDao productDao;

    //事务管理器对象
    @Autowired
    private PlatformTransactionManager transactionManager;
    //事务定义对象
    @Autowired
    private TransactionDefinition transactionDefinition;

    public void addOrder(Order order) {

        order.setCreateTime(new Date());
        order.setStatus("待付款");

        //开启一个事务,获得一个事务状态对象，就开启了一个事务了
        TransactionStatus transactionStatus = transactionManager.getTransaction(transactionDefinition);

        //下面的Dao的持久化操作以事务的方式封装起来
        try {
            orderDao.insert(order);
            Product product = productDao.select(order.getProductsId());
            product.setStock(product.getStock() - order.getNumber());
            productDao.update(product);
        }catch (Exception e){
            //发生异常，调用rollback方法回滚事务
            transactionManager.rollback(transactionStatus);
        }

        //事务的提交
        transactionManager.commit(transactionStatus);
    }
}

下面看一个订单支付的例子：

image-20210331142124265

@Transactional
public int payBill(String billId){ 
	// 获取账单信息
    Bill bill=billService.getById(billId);
    //调用第三方支付系统支付订单
    String flag=payService.invoke(url,bill); //返回支付状态
    
    //插入支付流水信息
    Bill uptBill=new Bill();
    uptBill.setUuid(bill.getUuid);
    uptBill.setBillStatus(flag);
    billService.update(uptBill);
}

乍一看，上述支付代码很完美，会不会存在什么问题呢.......
如果有1000个用户同时在线支付，第三方支付系统吞吐量不够，每秒只能处理100个支付任务的情况下，会出现什么问题呢？
对于一个只设置了500个连接数的数据库会不会出问题呢？答案是肯定的，因为使用@Transactional声明事务，调用支付方法时，每个请求会单独占用一个数据库连接，直到支付完成后才会释放连接。
如果使用编程式事务，会怎么样呢？

@Autowired
private TransactionTemplate transactionTemplate; //声明事务模板
public int payBill(String billId){ 
    Bill bill=billService.getById(billId);
    transactionTemplate.execute(new TransactionCallback<Object>() {
                @Override
                public Object doInTransaction(TransactionStatus transactionStatus) {
                    Bill uptBill=new Bill();
                   uptBill.setUuid(bill.getUuid);
                   uptBill.setBillStatus(2); //正在支付
                   billService.update(uptBill);
                    return null;
                }
     });
    //调用第三方支付系统支付订单
    String flag=payService.invoke(url,bill);
    //返回支付状态
    transactionTemplate.execute(new TransactionCallback<Object>() {
                @Override
                public Object doInTransaction(TransactionStatus transactionStatus) {
                    Bill uptBill=new Bill();
                   uptBill.setUuid(bill.getUuid);
                   uptBill.setBillStatus(flag); 
                   billService.update(uptBill);
                    return null;
                }
     });
}

八、总结

声明式事务管理方法允许开发者配置的帮助下来管理事务，而不需要依赖底层API进行硬编码。开发者可以只使用注解或基于配置的 XML 来管理事务。

声明式事务管理使用了 AOP 实现的，本质就是在目标方法执行前后进行拦截。 在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。使用这种方式，对代码没有侵入性，方法内只需要写业务逻辑就可以了。

首先，声明式事务有一个局限，那就是他的最小粒度要作用在方法上。

也就是说，如果想要给一部分代码块增加事务的话，那就需要把这个部分代码块单独独立出来作为一个方法。

但是，正是因为这个粒度问题，本人并不建议过度的使用声明式事务。

首先，因为声明式事务是通过注解的，有些时候还可以通过配置实现，这就会导致一个问题，那就是这个事务有可能被开发者忽略。

事务被忽略了有什么问题呢？

首先，如果开发者没有注意到一个方法是被事务嵌套的，那么就可能会再方法中加入一些如RPC远程调用、消息发送、缓存更新、文件写入等操作。

我们知道，这些操作如果被包在事务中，有两个问题：

1、这些操作自身是无法回滚的，这就会导致数据的不一致。可能RPC调用成功了，但是本地事务回滚了，可是PRC调用无法回滚了。

2、在事务中有远程调用，就会拉长整个事务。那么久会导致本事务的数据库连接一直被占用，那么如果类似操作过多，就会导致数据库连接池耗尽。

有些时候，即使没有在事务中进行远程操作，但是有些人还是可能会不经意的进行一些内存操作，如运算。或者如果遇到分库分表的情况，有可能不经意间进行跨库操作。

但是如果是编程式事务的话，业务代码中就会清清楚楚看到什么地方开启事务，什么地方提交，什么时候回滚。这样有人改这段代码的时候，就会强制他考虑要加的代码是否应该方法事务内。

Copyright: 采用 知识共享署名4.0 国际许可协议进行许可

Links: https://alone95.cn/archives/spring事务以及声明事务失效的几种原因

# Spring事务

（非原创）规则引擎Drools讲义