@Transactional 事务注解

Z时代
2024-01-10
分类：综合

本文内容纲要：@Transactional 事务注解

@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.SERIALIZABLE, rollbackFor = Exception.class) 简单解析：如果有事务，那么加入事务，没有的话新建一个；串行化最高级隔离级别；遇到异常回滚。

@Transactional之value

value这里主要用来指定不同的事务管理器；主要用来满足在同一个系统中，存在不同的事务管理器。比如在Spring中，声明了两种事务管理器txManager1, txManager2.

然后，用户可以根据这个参数来根据需要指定特定的txManager.

@Transactional之propagation（service中调用其他service时需要注意）

@Transactional(propagation=Propagation.REQUIRED)	如果有事务，那么加入事务，没有的话新建一个(默认情况下)
@Transactional(propagation=Propagation.NOT_SUPPORTED)	容器不为这个方法开启事务
@Transactional(propagation=Propagation.REQUIRES_NEW)	不管是否存在事务，都创建一个新的事务，原来的挂起，新的执行完毕，继续执行老的事务
@Transactional(propagation=Propagation.MANDATORY)	必须在一个已有的事务中执行，否则抛出异常
@Transactional(propagation=Propagation.NEVER)	必须在一个没有的事务中执行，否则抛出异常(与Propagation.MANDATORY相反)
@Transactional(propagation=Propagation.SUPPORTS)	如果其他bean调用这个方法，在其他bean中声明事务，那就用事务。如果其他bean没有声明事务，那就

Propagation支持7种不同的传播机制：

REQUIRED

业务方法需要在一个事务中运行,如果方法运行时,已处在一个事务中,那么就加入该事务,否则自己创建一个新的事务.这是spring默认的传播行为.。

SUPPORTS：

如果业务方法在某个事务范围内被调用,则方法成为该事务的一部分,如果业务方法在事务范围外被调用,则方法在没有事务的环境下执行。

MANDATORY：

只能在一个已存在事务中执行,业务方法不能发起自己的事务,如果业务方法在没有事务的环境下调用,就抛异常

REQUIRES_NEW

业务方法总是会为自己发起一个新的事务,如果方法已运行在一个事务中,则原有事务被挂起,新的事务被创建,直到方法结束,新事务才结束,原先的事务才会恢复执行.

NOT_SUPPORTED

声明方法需要事务,如果方法没有关联到一个事务,容器不会为它开启事务.如果方法在一个事务中被调用,该事务会被挂起,在方法调用结束后,原先的事务便会恢复执行.

NEVER：

声明方法绝对不能在事务范围内执行,如果方法在某个事务范围内执行,容器就抛异常.只有没关联到事务,才正常执行.

NESTED：

如果一个活动的事务存在,则运行在一个嵌套的事务中.如果没有活动的事务,则按REQUIRED属性执行.它使用了一个单独的事务, 这个事务拥有多个可以回滚的保证点.内部事务回滚不会对外部事务造成影响, 它只对DataSourceTransactionManager 事务管理器起效.

其实大家最感到困惑的是REQUIRED_NEW和NESTED两种不同的传播机制，功能类似，都涉及到了事务嵌套的问题，那两者有何区别呢？该如何正确使用这两种模式呢？

以下是摘自Spring的文档：

PROPAGATION_REQUIRES_NEW : uses a completely independent transaction for each affected transaction scope. In that case, the underlying physical transactions are different and hence can commit or roll back independently, with an outer transaction not affected by an inner transaction's rollback status.

内部的事务独立运行，在各自的作用域中，可以独立的回滚或者提交；而外部的事务将不受内部事务的回滚状态影响。

ROPAGATION_NESTED : uses a single physical transaction with multiple savepoints that it can roll back to. Such partial rollbacks allow an inner transaction scope to trigger a rollback for its scope, with the outer transaction being able to continue the physical transaction despite some operations having been rolled back. This setting is typically mapped onto JDBC savepoints, so will only work with JDBC resource transactions.

NESTED的事务，基于单一的事务来管理，提供了多个保存点。这种多个保存点的机制允许内部事务的变更触发外部事务的回滚。而外部事务在混滚之后，仍能继续进行事务处理，即使部分操作已经被混滚。由于这个设置基于JDBC的保存点，所以只能工作在JDBC的机制智商。

由此可知，两者都是事务嵌套，不同之处在于，内外事务之间是否存在彼此之间的影响；NESTED之间会受到影响，而产生部分回滚，而REQUIRED_NEW则是独立的。

@Transactional之isolation（多使用与多用户并发操作数据库，注意会引发的并发问题）

@Transactional(isolation = Isolation.READ_UNCOMMITTED)	读取未提交数据(会出现脏读，不可重复读) 基本不使用
@Transactional(isolation = Isolation.READ_COMMITTED)(SQLSERVER默认)	读取已提交数据(会出现不可重复读和幻读)
@Transactional(isolation = Isolation.REPEATABLE_READ)	可重复读(会出现幻读)
@Transactional(isolation = Isolation.SERIALIZABLE)	串行化

隔离级别所要解决的问题是在应用程序中，存在多个事务同时在运行之时，需要解决和处理好的问题。那首先来看看，一般会出现哪些问题呢？先来看看吧。

脏读（dirty read)

一个事物更新了数据库中的某些数据，另一个事物读取了这些数据，这时前一个事物由于某些原因回滚了，那么第二个事物读取的数据就是“脏数据”

不可重复读（non-repeatable read)

一个事物需要两次查询同一数据，但两次查询中间可能有另外一个事物更改了这个数据，导致前一个事物两次读出的数据不一致。

幻读（phantom read)

一个事物两次查询同一个表，但两次查询中间可能有另外一个事物又向这个表中插入了一些新数据，导致前一个事物的两次查询不一致

下面来看看Spring中@Transactional中Isolation有具备的值：

DEFAULT 使用各个数据库默认的隔离级别

Read Uncommited :读未提交数据( 会出现脏读,不可重复读,幻读 )

Read Commited :读已提交的数据(会出现不可重复读,幻读)

Repeatable Read :可重复读(会出现幻读)

Serializable :串行化

具体如何来设置具体的隔离界别，则依据业务系统具体可以容忍的程度而定。Serializable最为严格，然而效率最低；Read Uncommited效率最高，但是容易出现各种问题，中间的2个级别介于二者之间，故本质上是效率与出错概率的平衡与妥协。

@Transactional之timeout

用于设置事务处理的时间长度，阻止可能出现的长时间的阻塞系统或者占用系统资源。单位为秒。如果超时设置事务回滚，并抛出TransactionTimedOutException异常。

Spring事务超时 = 事务开始时到最后一个Statement创建时时间 + 最后一个Statement的执行时超时时间（即其queryTimeout）。

关于事务超时时间的计算可以参考：http://jinnianshilongnian.iteye.com/blog/1986023

@Transactional之readOnly

默认情况下是false，可以显示指定为true，告诉程序该方法下使用的是只读操作，如果进行其他非读操作，则会跑出异常；这个紧紧适用于只有readOnly标识的情况下，当其与propagation机制同时使用之时，则会出现只读设置被覆盖的情况，比如在required的情况下。在使用 REQUIRED 传播模式时，会抛出一个只读连接异常。使用 JDBC 时是这样。使用基于 ORM 的框架时，只读标志只是对数据库的一个提示，并且一条基于 ORM 框架的指令（本例中是 hibernate）将对象缓存的 flush 模式设置为 NEVER，表示在这个工作单元中，该对象缓存不应与数据库同步。不过，REQUIRED 传播模式会覆盖所有这些内容，允许事务启动并工作，就好像没有设置只读标志一样。

具体的详细内容可以参考： http://robinsoncrusoe.iteye.com/blog/825531

@Transactional之rollbackForClassName/rollbackFor

Spring默认情况下会对运行期例外(RunTimeException)进行事务回滚。这个例外是unchecked，如果遇到checked意外就不回滚。

用来指明回滚的条件是哪些异常类或者异常类名。用法比较简单，这些不再赘述。

@Transactional之noRollbackForClassName/noRollbackFor

作用雷同于8，用来指明在抛出特定异常的情况下，不进行数据库的事务回滚操作。

spring事务回滚规则

指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。

默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚。

可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。

还可以编程性的通过setRollbackOnly()方法来指示一个事务必须回滚，在调用完setRollbackOnly()后你所能执行的唯一操作就是回滚。

Spring @Transactional的注意事项

@Transactional 注解应该只被应用到 public 可见度的方法上。如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错，但是这个被注解的方法将不会展示已配置的事务设置。

用 spring 事务管理器，由spring来负责数据库的打开，提交，回滚。默认遇到运行期异常(throw new RuntimeException("注释");)会回滚，即遇到不受检查（unchecked）的异常时回滚；而遇到需要捕获的异常(throw new Exception("注释");)不会回滚，即遇到受检查的异常（就是非运行时抛出的异常，编译器会检查到的异常叫受检查异常或说受检查异常）时，需我们指定方式来让事务回滚要想所有异常都回滚，要加上 @Transactional( rollbackFor={Exception。class，其它异常}) 。

@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。然而，请注意仅仅 @Transactional 注解的出现不足于开启事务行为，它仅仅是一种元数据，能够被可以识别 @Transactional 注解和上述的配置适当的具有事务行为的beans所使用。上面的例子中，其实正是 tx:annotation-driven/元素的出现开启了事务行为。

Spring团队的建议是你在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。你当然可以在接口上使用 @Transactional 注解，但是这将只能当你设置了基于接口的代理时它才生效。因为注解是不能继承的，这就意味着如果你正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装（将被确认为严重的）。因此，请接受Spring团队的建议并且在具体的类上使用 @Transactional 注解。