事务的再次认知

最新推荐文章于 2024-03-15 10:15:00 发布

Vick_Zhang

最新推荐文章于 2024-03-15 10:15:00 发布

阅读量282

点赞数

分类专栏： java database

java 同时被 2 个专栏收录

30 篇文章

订阅专栏

database

16 篇文章

订阅专栏

本文深入解析数据库事务的概念、ACID特性及其四种隔离级别，探讨乐观锁与悲观锁的应用场景，并介绍Spring事务管理的具体实践。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

自学生时代对事务有所认识，后来便逐渐忘却。现在来重新认识一下。
事务：事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。
事务是恢复和并发控制的基本单位，是用户定义的一系列操作，这些操作要么完全地执行，要么完全不执行，是一个不可分割的工作单位。
事务的作用：…没找到我满意的表述
事务的四个特性：原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)。（ACID）
原子性(atomicity)：强调事务是不可分割的最小单元，对于数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖人。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。
一致性(consistency)：一旦一个事务结束了（不管成功与否），系统所处的状态和它的业务规则是一致的。即数据应当不会被破坏。
隔离性(isolation)：由并发事务所作的修改必须与任何其他并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为隔离性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结事时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结与通进连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。
持久性(durability)：事务完成后，它对于系统的影响是永久性的。该修改即使出现致命系统故障也将一直保持。
事务有三种模型：
1．隐式事务是指每一条数据操作语句都自动地成为一个事务，事务的开始是隐式的，事务的结束有明确的
标记。
2．显式事务是指有显式的开始和结束标记的事务，每个事务都有显式的开始和结束标记。
3．自动事务是系统自动默认的，开始和结束不用标记。
并发控制
1．数据库系统一个明显的特点是多个用户共享数据库资源，尤其是多个用户可以同时存取相同数据。
串行控制：如果事务是顺序执行的，即一个事务完成之后，再开始另一个事务
并行控制：如果DBMS可以同时接受多个事务，并且这些事务在时间上可以重叠执行。
2．并发控制概述
事务是并发控制的基本单位，保证事务ACID的特性是事务处理的重要任务，而并发操作有可能会破坏其ACID特性。
DBMS并发控制机制的责任：
对并发操作进行正确调度，保证事务的隔离性更一般，确保数据库的一致性。
如果没有锁定且多个用户同时访问一个数据库，则当他们的事务同时使用相同的数据时可能会发生问题。由于并发操作带来的数据不一致性包括：丢失数据修改、读”脏”数据（脏读）、不可重复读、产生幽灵数据。
（1）丢失数据修改
当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。如上例。
再例如，两个编辑人员制作了同一文档的电子复本。每个编辑人员独立地更改其复本，然后保存更改后的复本，这样就覆盖了原始文档。最后保存其更改复本的编辑人员覆盖了第一个编辑人员所做的更改。如果在第一个编辑人员完成之后第二个编辑人员才能进行更改，则可以避免该问题。
（2）读“脏”数据（脏读）
读“脏”数据是指事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被除撤消，而此时T1把已修改过的数据又恢复原值，T2读到的数据与数据库的数据不一致，则T2读到的数据就为“脏”数据，即不正确的数据。
例如：一个编辑人员正在更改电子文档。在更改过程中，另一个编辑人员复制了该文档（该复本包含到目前为止所做的全部更改）并将其分发给预期的用户。此后，第一个编辑人员认为所做的更改是错误的，于是删除了所做的编辑并保存了文档。分发给用户的文档包含不再存在的编辑内容，并且这些编辑内容应认为从未存在过。如果在第一个编辑人员确定最终更改前任何人都不能读取更改的文档，则可以避免该问题。
（ 3）不可重复读
指事务T1读取数据后，事务T2执行更新操作，使T1无法读取前一次结果。不可重复读包括三种情况：
事务T1读取某一数据后，T2对其做了修改，当T1再次读该数据后，得到与前一不同的值。
（4）产生幽灵数据
按一定条件从数据库中读取了某些记录后，T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录消失
T1按一定条件从数据库中删除某些数据记录后，T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。

写问题：丢失更新
1)产生丢失更新的原因
丢失更新就是两个不同的事务（或者开启两个线程）在某一时刻对同一数据进行读取后，先后进行修改。导致第一次操作数据丢失。
2)解决方式
使用数据库锁机制防止数据丢失
(1)共享锁
共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享 (S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享 (S) 锁
(2)排它锁
排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。

读问题：脏读、不可重复读、幻度
脏读:一个事务读取到另一个事务的未提交数据
【注释说明】例如在执行update操作时，这个事务未提交，数据库的数据就没有发生该表；此时再执行select操作时，第二个事务就能读取到更新数据之后的数据信息；问题是数据库的数据没有发生改变，但select查询的数据是与数据库中的数据不一致了。

不可重复读:一个事务两次读同一行数据，可是这两次读到的数据不一样。[一个事务读取到另一个事务提交的数据(主要是指update)，会导致两次读取的结果不一致。]

幻读(虚读): 一个事务执行两次查询，但第二次查询比第一次查询多出了一些数据行。[一个事务读取到另一个事务提交的数据(主要是指insert),会导致两次读取结果不一致。]

问题:对于上述问题如何解决?
我们可以通过设置隔离级别来解决读的问题.
处理事务：效率越来越低，但安全性越来越高
READ_UNCOMMITED 读未提交：它引发所有的隔离问题
READ_COMMITTED 读已提交:　　阻止脏读,可能发生不可重复读与虚读.
REPEATABLE_READ 可重复读: 　　阻止脏读，不可重复读：可能发生虚读
SERIALIZABLE 串行化: 　　解决所有问题不允许两个事务，同时操作一个目标数据。（效率低下，但操作安全是最安全的）

ORACLE 默认的是事务隔离级别 READ_COMMITTED
MYSQL 默认的事务隔离级别 REPEATABLE_READ

Hibernate中设置事务隔离级别
hibernate.connection.isolation
它可取的值有 1 2 4 8
1代表的事务隔离级别为　　READ UNCOMMITTED
2代表的事务隔离级别为　　READ COMMITTED
4.代表的事务隔离级别为　REPEATABLE READ
8代表的事务隔离级别为　　SERIALIZABLE
在hibernate.cfg.xml文件中配置

< property name=”hibernate.connection.isolation”>4
设置之后，在开始一个事务之前，Hibernate将为从连接池中获得的JDBC连接设置级别。需要注意的是，在受管理环境中，如果Hibernate使用的数据库连接来自于应用服务器提供的数据源，Hibernate不会改变这些连接的事务隔离级别。在这种情况下，应该通过修改应用服务器的数据源配置来修改隔离级别。
2. 数据库事务声明：
数据库系统的客户程序只要向数据库系统声明了一个事务，数据库系统就会自动保证事务的ACID特性。在JDBC API中，java.sql.Connection类代表一个数据库连接。它提供了以下方法控制事务：
1. setAutoCommit(Boolean autoCommit)：设置是否自动提交事务。
2. commit()：提交事务。
3. rollback()：撤销事务。
2.1. JDBC API声明事务的示例代码如下：

Connection = null;
PreparedStatement pstmt = null;
try{
con = DriverManager.getConnection(dbUrl, username, password);
//设置手工提交事务模式
con.setAutoCommit(false);
pstmt = ……;
pstmt.executeUpdate();
//提交事务
con.commit();
}catch(Exception e){
//事务回滚
con.rollback();
…..
} finally{
    …….
}

Hibernate对JDBC进行了轻量级的对象封装，Hibernate本身在设计时并不具备事务处理功能，平时所用的Hibernate的事务，只是将底层的JDBCTransaction或者JTATransaction进行了一下封装，在外面套上Transaction和Session的外壳，其实底层都是通过委托底层的JDBC或JTA来实现事务的调度功能。
2.2. Hibernate中使用JDBC事务：
要在Hibernate中使用事务，可以配置Hibernate事务为JDBCTransaction或者JTATransaction，这两种事务的生命周期不一样，可以在hibernate.cfg.xml中指定使用的是哪一种事务。以下配置为使用JDBC事务。注：如果不进行配置，Hibernate也会默认使用JDBC事务。

<session-factory>
……
<property name="hibernate.transaction.factory_class">
org.hibernate.transaction.JDBCTransactionFactory
</property>
……
</session-factory>

Hibernate 使用JDBC transaction处理方式如下所示：

Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // do some work
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

2.3. Hibernate中使用JTA事务：
JTA(java Transaction API)是事务服务的JavaEE解决方案。本质上，它是描述事务接口的JavaEE模型的一部分。
JTA具有的3个接口：UserTransaction接口、TransactionManager接口和Transaction接口，这些接口共享公共的事务操作。UserTransaction能够执行事务划分和基本的事务操作，TransactionManager能够执行上下文管理。
在一个具有多个数据库的系统中，可能一个程序将会调用几个数据库中的数据，需要一种分布事务，或者准备用JTA来管理Session的长事务，那么就需要使用JTATransaction。
在hibernate.cfg.xml中配置JTA事务管理：

<session-factory>
……
<property name="hibernate.transaction.factory_class">
org.hibernate.transaction.JTATransactionFactory
</property>
……
</session-factory>

下面是一个实际应用的JTA示例：

// BMT(bean管理事务) idiom with getCurrentSession()
try {
    UserTransaction tx = (UserTransaction)new InitialContext()
                            .lookup("java:comp/UserTransaction");

    tx.begin();

    // Do some work on Session bound to transaction
    factory.getCurrentSession().load(...);
    factory.getCurrentSession().persist(...);

    tx.commit();
}
catch (RuntimeException e) {
    tx.rollback();
    throw e; // or display error message
}

在CMT方式下，事务声明是在session bean的部署描述符中，而不需要编程。因此，代码被简化为：

// CMT idiom
Session sess = factory.getCurrentSession();

// do some work
...

5. 并发控制：
当数据库系统采用Red Committed隔离级别时，会导致不可重复读和第二类丢失更新的并发问题，在可能出现这种问题的场合。可以在应用程序中采用悲观锁或乐观锁来避免这类问题。
插播一条重要信息：数据库的锁机制：太他妈长了，在此贴上链接，就不手工搬运了
https://blog.youkuaiyun.com/samjustin1/article/details/52210125

5.1. 乐观锁(Optimistic Locking)：
乐观锁假定当前事务操纵数据资源时，不会有其他事务同时访问该数据资源，因此不作数据库层次上的锁定。为了维护正确的数据，乐观锁使用应用程序上的版本控制（由程序逻辑来实现的）来避免可能出现的并发问题。
唯一能够同时保持高并发和高可伸缩性的方法就是使用带版本化的乐观并发控制。版本检查使用版本号、或者时间戳来检测更新冲突（并且防止更新丢失）。
5.1.1. 使用版本检查()：
Hibernate中通过版本号检查来实现后更新为主，这也是Hibernate推荐的方式。在数据库表中加入一个version(版本)字段，在读取数据时连同版本号一起读取，并在更新数据时比较版本号与数据库表中的版本号，如果等于数据库表中的版本号则予以更新，并递增版本号，如果小于数据库表中的版本号就抛出异常。
使用进行版本控制的步骤：
1) 在持久化类中定义一个代表版本号的属性：

package org.qiujy.domain.versionchecking;

import java.util.Date;

public class Product implements java.io.Serializable{
       private Long id ;
       /** 版本号 */
       private int version;
       private String name; //产品名
       private String description; //描述--简介
       private Double unitCost; //单价
       private Date pubTime; //生产日期

       public Product(){}

       //以下为getter()和setter()方法
}

2) 在Product.hbm.xml文件中用元素来建立Product类的version属性与表中version字段的映射。
3) Hibernate在其数据库访问引擎中内置了乐观锁定实现，默认也是选择version方式作为Hibernate乐观锁定实现机制。所以，在配置文件及程序中可以不作其它设置。按往常一样写操作代码。

package org.qiujy.domain.versionchecking;

import java.util.Date;

import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.Transaction;
import org.qiujy.common.HibernateSessionFactory;

public class TestVersionChecking {

       public static void main(String[] args) {
              Product prod = new Product();
              prod.setName("IBM thinkPad T60");
              prod.setUnitCost(new Double(26000.00));
              prod.setDescription("笔记本电脑");
              prod.setPubTime(new Date());

              //test start.......
              Session session = HibernateSessionFactory.getSession();
              Transaction tx =null;
              try{
                     tx = session.beginTransaction();

                     session.save(prod);
               　
                    tx.commit();
              }catch(HibernateException e){
                     if(tx != null){
                            tx.rollback();
                     }
                     e.printStackTrace();
              }finally{
                     HibernateSessionFactory.closeSession();
              }

//进行更新 测试..
              prod.setDescription("新款的");

              Session session2 = HibernateSessionFactory.getSession();
              Transaction tx2 =null;
              try{
                     tx2 = session2.beginTransaction();

                     session2.update(prod);

                    tx2.commit();
              }catch(HibernateException e){
                     if(tx2 != null){
                            tx2.rollback();
                     }
                     e.printStackTrace();
              }finally{
                     HibernateSessionFactory.closeSession();
              }
       }
}

新增数据时产生的SQL是：

insert into products (version, name, description, unitCost, pubTime)
    values(?, ?, ?, ?, ?)

程序无需为Product对象的version属性显示赋值，当持久化一个Product对象时,Hibernate会自动为它赋初始值为0。
更新数据时产生的SQL是：

update
        products
    set
        version=?,
        name=?,
        description=?,
        unitCost=?,
        pubTime=?
    where
        id=?
        and version=?

当Hibernate更新一个Product对象，会根据它的id和version属性到相应的数据库表中定位匹配的记录，如果存在这条匹配的记录，就更新记录，并且把version字段的值加1。若找不到匹配的记录，此时Hibernate会抛出StaleObjectStateException。

需要注意的是，由于乐观锁定是使用系统中的程序来控制，而不是使用数据库中的锁定机制，因而如果有人故意自行更新版本信息来超过检查，则锁定机制就无效。所以建议把持久化类中的version的get方法设置为private的。
5.1.2. 使用时间戳()：
跟版本检查的用法相似。不再多说。
5.2. 悲观锁(Pessimistic Locking)：
悲观锁假定当前事务操纵数据资源时，肯定还会有其他事务同时访问该数据资源，为了避免当前事务的操作受到干扰，先锁定资源。尽管悲观锁能够防止丢失更新和不可重复读这类并发问题，但是它影响并发性能，因此应该很谨慎地使用悲观锁。

乐观锁
在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。

乐观锁（ Optimistic Locking ）相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

数据版本,为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。

实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。

使用版本号实现乐观锁
使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。

1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。

悲观锁
在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。
悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）

在数据库中，悲观锁的流程如下：
在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。

如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。

如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。

其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

MySQL InnoDB中使用悲观锁
要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0;

//0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;

上面的查询语句中，我们使用了select…for update的方式，这样就通过开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。
优点与不足
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数

最后说一说现在常用的做法：spring管理事务
在谈Spring事务管理之前我们想一下在我们不用Spring的时候，在Hibernate中我们是怎么进行数据操作的。在Hibernate中我们每次进行一个操作的的时候我们都是要先开启事务，然后进行数据操作，然后提交事务，关闭事务，我们这样做的原因是因为Hibernate默认的事务自动提交是false，他是需要我们人为的手动提交事务，假如你不想每次都手动提交事务的话，你可以在hibernate.cfg.xml我文件中把它设置为事务自动提交：

<!-- 配置事务管理器 指定其作用的sessionFactory把事务交给Spring去处理 -->

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

<!-- 配置事务的传播特性 -->
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="save*" propagation="REQUIRED"/>
<tx:method name="delete*" propagation="REQUIRED"/>
<tx:method name="update*" propagation="REQUIRED"/>
<tx:method name="get*" read-only="true" propagation="NOT_SUPPORTED"/>
<tx:method name="*" read-only="true"/>
</tx:attributes>
</tx:advice>

<!-- 那些类的哪些方法参与事务 -->
<aop:config>
<aop:pointcut id="allServiceMethod" expression="execution(* com.coe.service.*.*(..))"/>
<aop:advisor pointcut-ref="allServiceMethod" advice-ref="txAdvice"/>
</aop:config>

我们在配置事务的时候，我们一般是把事务边界设置到service层，也就是你的业务逻辑层，因为我们很多时候都是在我们的业务逻辑层来完成我们一些列的数据操作，如果放到Dao数据层，其粒度太小了。另外，如果我们把事务配置在业务逻辑层的话，对我们的二级缓存也是有好处的，这个大家以后实际操作的时候会发现。

2、编写业务逻辑方法

这时候我们就可以在我们业务逻辑层用HibernateTemplate里面提供的数据操作方法来编写我们的业务逻辑方法了，当然我们的方法必须要是以我们事务配置里面配置的一样，用save，delete，update，get做我们的方法的开头。需要注意的是，默认情况下运行期异常才会回滚（包括继承了RuntimeException子类），普通异常是不会滚的。

最后我们顺便总结一下事务的几种传播特性：

PROPAGATION_REQUIRED: 如果存在一个事务，则支持当前事务。如果没有事务则开启；
PROPAGATION_SUPPORTS: 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行；
PROPAGATION_MANDATORY: 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常；
PROPAGATION_REQUIRES_NEW: 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起；
PROPAGATION_NOT_SUPPORTED: 总是非事务地执行，并挂起任何存在的事务；
PROPAGATION_NEVER: 总是非事务地执行，如果存在一个活动事务，则抛出异常；
PROPAGATION_NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行。