Spring的事务管理(一) Spring事务管理的实现，事务的属性(隔离级别，传播行为，只读)

最新推荐文章于 2025-03-04 15:03:00 发布

z1340954953

最新推荐文章于 2025-03-04 15:03:00 发布

阅读量984

点赞数

分类专栏： Spring 文章标签：数据库的隔离级别事务的传播属性 spring中事务管理的策略

Spring 专栏收录该内容

16 篇文章

订阅专栏

Spring中事务的管理具体策略

Spring事务管理中涉及到的接口

事务管理器

Spring并不直接管理事务，而是提供了一个接口org.springframework.transaction.PlatformTransactionManager，具体的实现交由各个平台jdbc,hibernate等等自己实现。

public abstract interface PlatformTransactionManager
{
  public abstract TransactionStatus getTransaction(TransactionDefinition paramTransactionDefinition)
    throws TransactionException;
  
  public abstract void commit(TransactionStatus paramTransactionStatus)
    throws TransactionException;
  
  public abstract void rollback(TransactionStatus paramTransactionStatus)
    throws TransactionException;
}

* jdbc事务管理器

如果应用程序中直接使用JDBC来进行持久化，DataSourceTransactionManager会为你处理事务边界。

为了使用DataSourceTransactionManager，你需要使用如下的XML将其装配到应用程序的上下文定义中：

  <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource" />
  </bean>

DataSourceTransactionManager是通过调用Connection来管理事务，通过调用Connection的commit方法提交事务，rollback方法回滚事务

* Hiberante事务

Hibernate持久化策略，利用HibernateTransactionManager进行事务管理。对于Hibernate3，需要在Spring上下文定义中添加如下的<bean>声明：

<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
</bean>

sessionFactory属性需要装配一个Hibernate的session工厂，HibernateTransactionManager的实现细节是它将事务管理的职

责委托给org.hibernate.Transaction对象，而后者是从Hibernate Session中获取到的。

当事务成功完成时，HibernateTransactionManager将会调用Transaction对象的commit()方法，反之，将会调用rollback()方法。

* JPA事务

Hibernate多年来一直是事实上的Java持久化标准，但是现在Java持久化API作为真正的Java持久化标准进入大家的视野。

如果你计划使用JPA的话，那你需要使用Spring的JpaTransactionManager来处理事务。你需要在Spring中这样配置JpaTransactionManager：

  <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>

JpaTransactionManager只需要装配一个JPA实体管理工厂（javax.persistence.EntityManagerFactory接口的任意实现）。

JpaTransactionManager将与由工厂所产生的JPA EntityManager合作来构建事务。

* Java原生API事务

如果你没有使用以上所述的事务管理，或者是跨越了多个事务管理源（比如两个或者是多个不同的数据源），你就

需要使用JtaTransactionManager：

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
        <property name="transactionManagerName" value="java:/TransactionManager" />
</bean>

JtaTransactionManager将事务管理的责任委托给javax.transaction.UserTransaction

和javax.transaction.TransactionManager对象，其中事务成功完成通过UserTransaction.commit()方法提交，事务

失败通过UserTransaction.rollback()方法回滚。

事务属性的定义

前面介绍Spring中通过PlatformTransactionManager的方法getTransaction(TransactionDefinition）获取事务，类

TransactionDefinition定义了一些事务的基本属性。

事务属性可以理解成事务的一些基本配置，描述了事务策略如何应用到方法上。事务属性包含了5个方面，如图

接口TransactionDefinition定义事务的属性

public interface TransactionDefinition {
    int getPropagationBehavior(); // 返回事务的传播行为
    int getIsolationLevel(); // 返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以看到本事务内的哪些数据
    int getTimeout();  // 返回事务必须在多少秒内完成
    boolean isReadOnly(); // 事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的
}

* 只读

事务的第三个特性是它是否为只读事务。如果事务只对后端的数据库进行该操作，数据库可以利用事务的只读特性来进行一些特定的优化。通过将事务设置为只读，数据库会提供优化

* 事务超时

为了使应用程序很好地运行，事务不能运行太长的时间。因为事务可能涉及对后端数据库的锁定，所以长时间的事务会不必要的占用数据库资源。事务超时就是事务的一个定时器，在特定时间内事务如果没有执行完毕，那么就会自动回滚，而不是一直等待其结束。

* 回滚规则

这些规则定义了哪些异常会导致事务回滚而哪些不会。默认情况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行为是一致的）

但是你可以声明事务在遇到特定的检查型异常时像遇到运行期异常那样回滚。同样，你还可以声明事务遇到特定的异常不回滚，即使这些异常是运行期异常。

* 事务状态

上面讲到的调用PlatformTransactionManager接口的getTransaction()的方法得到的是TransactionStatus接口的一个实现，这个接口的内容如下：

public interface TransactionStatus{
    boolean isNewTransaction(); // 是否是新的事物
    boolean hasSavepoint(); // 是否有恢复点
    void setRollbackOnly();  // 设置为只回滚
    boolean isRollbackOnly(); // 是否为只回滚
    boolean isCompleted; // 是否已完成
}

可以发现这个接口描述的是一些处理事务提供简单的控制事务执行和查询事务状态的方法，在回滚或提交的时候需要应用对应的事务状态。

* 事务的隔离级别

数据库当同时存在两个或者两个以上的数据库事务环境，存在一些并发的问题。

脏读：一个事务读取到另一个事务没有提交的数据

不可重复读：A事务读取同一行记录读取两次，第一次读取一行记录，期间B事务修改了这行记录，并提交事务，A事务随后读取到的记录和前一次不一致

幻读：一个事务读取两次表，第一次去读取表的记录数，随后另一个事务往表中添加了一行记录，再次去读表的记录，发现多了一行记录，就像是凭空产生的。

数据库提供了四种隔离级别来解决？

read uncommitted: 未提交读，会出现脏读问题，是最低的隔离级别

read committed:提交读，只有事务提交了，才能读取，避免脏读，但是一个事务中两次读取的一行数据不一致的问题，会出现，也就是会出现不可以重复读问题。大多数数据库默认的事务隔离级别

repeatedable read:重复读，就是事务开启了，执行读取操作，不允许对这行数据的修改操作，避免了不可重复读问题。

但是仍会出现幻读问题，因为repeatedable read 是禁止了update操作，仍然可以insert。

serializable：串行。一个事务一个事务，排队执行，隔离级别最高，不会出现幻读问题，但是性能低。

事务的隔离级别
隔离级别/项目	脏读	不可重复读	幻读
read uncommitted	会	会	会
read committed	不会	会	会
repeatable read	不会	不会	会
Serializable	不会	不会	不会

* 事务的传播行为

传播行为指的是，方法之间的调用问题。在大部分情况下，事务处理都应该是一次性的全部成功或失败的。但是存在特殊情况，在批处理中，不能因为一个处理失败就全部失败，应该是每个批处理中的单元的事务都需要独立开来。

事务的传播行为
传播行为	解释	备注
PROPAGATION_REQUIRED	如果存在一个事务，则支持当前事务。如果没有事务则开启事务	Spring中默认的传播行为
PROPAGATION_SUPPORTS	如果存在一个事务，则支持当前事务。如果没有事务，则非事务的执行
PROPAGATION_MANDATORY	如果已经存在一个事务，则支持当前事务。如果没有一个活动的事务，则抛出异常
PROPAGATION_REQUIREDS_NEW	总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起	在批处理，信用卡还款处理，给每一个卡创建一个独立的事务，不会因为一个处理失败，全部失败
PROPAGATION_NOT_SUPPORTED	总是非事务的执行，并挂起任何存在的事务
PROPAGATION_NEVER	总是非事务的执行，如果已经存在一个事务，则抛出异常
PROPAGATION_NESTED	如果一个活动的事务存在，则运行在一个嵌套的事务中；如果没有活动事务，则按照PROPAGATION_REQUIRED属性执行(开启一个新的事务)

(1) PROPAGATION_REQUIRED: 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务

//事务属性 PROPAGATION_REQUIRED
methodA{
    ……
    methodB();
    ……
}

//事务属性 PROPAGATION_REQUIRED
methodB{
   ……
}

单独调用methodB方法，相当于

Main{ 
    Connection con=null; 
    try{ 
        con = getConnection(); 
        con.setAutoCommit(false); 

        //方法调用
        methodB(); 

        //提交事务
        con.commit(); 
    } Catch(RuntimeException ex) { 
        //回滚事务
        con.rollback();   
    } finally { 
        //释放资源
        closeCon(); 
    } 
}

Spring保证在methodB方法中所有的调用都获得到一个相同的连接。在调用methodB时，没有一个存在的事务，所以获得一个新

的连接，开启了一个新的事务。

单独调用MethodA时，在MethodA内又会调用MethodB.

main{ 
    Connection con = null; 
    try{ 
        con = getConnection(); 
        methodA(); 
        con.commit(); 
    } catch(RuntimeException ex) { 
        con.rollback(); 
    } finally {    
        closeCon(); 
    }  
}

调用方法A时候，没有事务就开启一个事务，MethodA调用MethodB，因为已经有事务，MethodB就加入这个事务

(2) PROPAGATION_SUPPORTS: 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。

//事务属性 PROPAGATION_REQUIRED
methodA(){
  methodB();
}

//事务属性 PROPAGATION_SUPPORTS
methodB(){
  ……
}

单独调用MethodB是非事务的执行，调用MethodA时候加入事务，MethodB支持事务执行

(3) PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常

//事务属性 PROPAGATION_REQUIRED
methodA(){
    methodB();
}

//事务属性 PROPAGATION_MANDATORY
    methodB(){
    ……
}

当单独调用methodB时，因为当前没有一个活动的事务，则会抛出异常throw new IllegalTransactionStateException(“Transaction

propagation ‘mandatory’ but no existing transaction found”);当调用methodA时，methodB则加入到methodA的事务中，事务地

执行。

(4) PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起

//事务属性 PROPAGATION_REQUIRED
methodA(){
    doSomeThingA();
    methodB();
    doSomeThingB();
}

//事务属性 PROPAGATION_REQUIRES_NEW
methodB(){
    ……
}

调用方法A相当于

main(){
    TransactionManager tm = null;
    try{
        //获得一个JTA事务管理器
        tm = getTransactionManager();
        tm.begin();//开启一个新的事务
        Transaction ts1 = tm.getTransaction();
        doSomeThing();
        tm.suspend();//挂起当前事务
        try{
            tm.begin();//重新开启第二个事务
            Transaction ts2 = tm.getTransaction();
            methodB();
            ts2.commit();//提交第二个事务
        } Catch(RunTimeException ex) {
            ts2.rollback();//回滚第二个事务
        } finally {
            //释放资源
        }
        //methodB执行完后，恢复第一个事务
        tm.resume(ts1);
        doSomeThingB();
        ts1.commit();//提交第一个事务
    } catch(RunTimeException ex) {
        ts1.rollback();//回滚第一个事务
    } finally {
        //释放资源
    }
}

在这里，我把ts1称为外层事务，ts2称为内层事务。从上面的代码可以看出，ts2与ts1是两个独立的事务，互不相干。Ts2是否成

功并不依赖于 ts1。如果methodA方法在调用methodB方法后的doSomeThingB方法失败了，而methodB方法所做的结果依然被

提交。而除了 methodB之外的其它代码导致的结果却被回滚了。使用PROPAGATION_REQUIRES_NEW,需要使用 JtaTransactionManager作为事务管理器。

（5）PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。使用PROPAGATION_NOT_SUPPOR

TED,也需要使用JtaTransactionManager作为事务管理器。（代码示例同上，可同理推出）

（6）PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常。

（7）PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefi

nition.PROPAGATION_REQUIRED 属性执行。这是一个嵌套事务,使用JDBC 3.0驱动时,仅仅支持DataSourceTransactionManag

er作为事务管理器。需要JDBC 驱动的java.sql.Savepoint类。有一些JTA的事务管理器实现可能也提供了同样的功能。使用PROP

AGATION_NESTED，还需要把PlatformTransactionManager的nestedTransactionAllowed属性设为true;而 nestedTransactionAllowed属性值默认为false。

//事务属性 PROPAGATION_REQUIRED
methodA(){
    doSomeThingA();
    methodB();
    doSomeThingB();
}

//事务属性 PROPAGATION_NESTED
methodB(){
    ……
}

单独调用methodB相当于事务属性为PROPAGATION_NESTED,开启一个新的事务，如果调用methodA相当于

main(){
    Connection con = null;
    Savepoint savepoint = null;
    try{
        con = getConnection();
        con.setAutoCommit(false);
        doSomeThingA();
        savepoint = con2.setSavepoint();
        try{
            methodB();
        } catch(RuntimeException ex) {
            con.rollback(savepoint);
        } finally {
            //释放资源
        }
        doSomeThingB();
        con.commit();
    } catch(RuntimeException ex) {
        con.rollback();
    } finally {
        //释放资源
    }
}

methodB方法调用前，将当前的状态保存到savepoint，如果methodB执行失败，回到savapoint,methodB后面的方法继续执行，但是如果doSomeThingB执行失败，包括methodB方法都将回滚。

嵌套事务，分为内层事务和外层事务，内层事务的失败不会影响外层事务，但是外层事务的失败，内层事务将回滚

支持：DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED时，需要JDBC 3.0以上驱动及1.4以上的JDK版本支持。其它的JTA TrasactionManager实现可能有不同的支持方式。

PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW比较

相同点：如果没有事务，都回去开启一个新的事务

不同点: PROPAGATION_REQUIRES_NEW 外层事务和内层事务是两个独立的事务，外层的失败不会引起内层事务的回滚。

内层事务的失败，也不会引起外层的回滚。是独立的两个事务。而PROPAGATION_NESTED 内层事务相对是外层事务的一个分支，内存事务的失败，不会影响到外层事务的失败，但是外层事务的事务失败，内层事务也失败。内层事务的等外层事务提交。

参考: https://blog.youkuaiyun.com/trigl/article/details/50968079