spring事务基本原理

浅浅的花香味﹌ 2022-06-15 01:42 184阅读 0赞

参考文章：http://www.cnblogs.com/xusir/p/3650522.html

1、事务管理方式：

spring支持编程式事务管理和声明式事务管理两种方式。

编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。

声明式事务管理建立在AOP之上的，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理代码，只需要在配置文件中做相关的事务规则声明（或通过基于@Transactional注解的方式），便可以将事务规则应用到业务逻辑中。

显然声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染，一个普通的POJO对象，只要加上注解就可以获得完全的事务支持。和编程式事务相比，声明式事务唯一不足的地方是，后者的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。

声明式事务管理也有两种常用的方式，一种是基于tx和aop名字空间的xml配置文件，另一种就是基于@Transactional注解。

2、自动提交（AutoCommit）与连接关闭时是否自动提交

默认情况下，数据库处于自动提交模式。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。

对于正常的事务管理，是一组相关的 操作处于一个事务之中，因此必须关闭数据库的自动提交模式。不过，这个我们不用担心，spring会将底层连接的自动提交特性设置为false。

org/springframework/jdbc/datasource/DataSourceTransactionManager.java

![Center][]

有些数据库连接池提供了关闭事务自动提交的设置，最好在设置连接池时就将其关闭。但c3p0没有提供这一特性，只能依靠spring来设置。

因为JDBC规范规定，当连接对象建立时应该处于自动提交模式，这是跨DBMS的缺省值，如果需要，必须显式的关闭自动提交。c3p0遵守这一规范，让客户代码来显式的设置需要的提交模式。

连接关闭时的是否自动提交

当一个连接关闭时，如果有未提交的事务应该如何处理？JDBC规范没有提及，c3p0默认的策略是回滚任何未提交的事务。这是一个正确的策略，但JDBC驱动提供商之间对此问题并没有达成一致。c3p0的autoCommitOnClose属性默认值是false，没有十分必要不要动它。或者可以显式的设置此属性为false，这样会更明确。

3、1）基于注解的声明式事务管理配置

spring-servlet.xml

<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource" />
    </bean>
    
    <tx:annotation-driven transaction-manager="txManager" />

还要在spring-servlet.xml中添加tx命名空间

2）不基于注解的声明式事务管理配置

Mybatis自动参与到Spring事务管理中，无需额外配置，只要org.mybatis.spring.SqlSessionFactoryBean引用的数据源与DataSourceTransactionManager引用的数据源一致即可，否则事务管理不起作用。

另外需要下载依赖包aopalliance.jar放置到WEB-INF/lib目录下。否则spring初始化时会报异常：

java.lang.NoClassDefFoundError: org/aopalliance/intercept/MethodInterceptor

4、spring事务特性

spring所有的事务管理策略类都继承自：org.springframework.transaction.PlatformTransactionManager接口，

public interface PlatformTransactionManager {
     
      TransactionStatus getTransaction(TransactionDefinition definition)
        throws TransactionException;
     
      void commit(TransactionStatus status) throws TransactionException;
     
      void rollback(TransactionStatus status) throws TransactionException;
    }

其中TransactionDefinition接口定义以下特性：

事务隔离级别：

a）脏读：一个事务读取到了另外一个事务没有提交的数据。

b）不可重复读：在同一个事务中，两次读取同一数据，得到内容不同。原因是在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读取到的数据可能是不一样的。这样就发生了在一个事务内两次读取到的数据是不一样的，因此称为不可重复读。

c）幻读：是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改了这个表中数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好像产生了幻觉一样。

隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition接口中定义了五个表示隔离级别的常量：

1）TransactionDefinition.ISOLATION\_DEFAULT：这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这个值就是TransactionDefinition.ISOLATION\_READ\_COMMITTED.

2）TransactionDefinition.ISOLATION\_READ\_UNCOMMITTED：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读、不可重复读和幻读，因此很少使用该隔离级别。

3）TransactionDefinition.ISOLATION\_READ\_COMMITED：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读这也是大多数情况下的推荐值。

4）TransactionDefinition.ISOLATION\_REPEATABLE\_READ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。该级别可以防止脏读和不可重复读。

5）TransactionDefinition.ISOLATION\_SERIALIZABLE：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下不会用到该级别。

事务传播行为

所谓事务的传播行为是指，如果在开启当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量：

1）TransactionDefinition.PROPAGATION\_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务，这个是默认值。

2）TransactionDefinition.PROPAGATION\_REQUIRES\_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。

3）TransactionDefinition.PROPAGATION\_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。

4）TransactionDefinition.PROPAGATION\_NOT\_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。

5）TransactionDefinition.PROPAGATION\_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。

6）TransactionDefinition.PROPAGATION\_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。

7）TransactionDefinition.PROPAGATION\_NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION\_REQUIRED。

事务超时：

所谓事务超时，是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成。则自动回滚该事务。在TransactionDefinition中以int的值来表示超时时间，其单位是秒。默认设置为底层事务系统的超时值，如果底层数据库事务系统没有设置超时值，那么就是none，没有超时限制。

事务只读属性

只读事务用于客户代码只读但不修改数据的情形，只读事务用于特定情景下的优化，比如使用Hibernate的时候。默认为读写事务。

5、spring事务回滚规则

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

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

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

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

6、@Transactional注解

![Center 1][]

用法：

@Transactional可以作用于接口、接口方法、类以及类方法上。当作用于类上时，该类的所有public方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该注解来覆盖类级别的定义。

虽然@Transactional注解可以作用于接口、接口方法、类以及类方法上，但是Spring建议不要在接口或者接口方法上使用该注解，因为只有在使用基于接口的代理时它才会生效。另外，@Transactional注解应该只被应用到public方法上，这是有spring aop的本质决定的。如果你在protected、private或者默认可见性的方法上使用@Transactional注解，这将被忽略，也不会抛出任何异常。

默认情况下，只有来自外部的方法调用才会被AOP代理捕获，也就是，类内部方法调用本类内部的其他方法并不会引起事务行为，即使被调用方法使用@Transactional注解进行修饰。（待测试：分两种情况，1）只是单纯的类内部方法调用，比如A方法调用B方法；2）外部方法调用了A方法，而A方法又调用了B方法）

@Transactional(readOnly = true)
    public class DefaultFooService implements FooService {
     
      public Foo getFoo(String fooName) {
        // do something
      }
     
      // these settings have precedence for this method
      //方法上注解属性会覆盖类注解上的相同属性
      @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
      public void updateFoo(Foo foo) {
        // do something
      }
    }

[Center]: /images/20220615/abbfacb57aab473dbe9a2db326faece1.png
[Center 1]: /images/20220615/cc5416bd800a4ec2ab14be62b75bb0d7.png