Spring @Transactional - 隔离、传播

Question

有人可以解释一下隔离和“隔离”吗？通过实际示例来了解 @Transactional 注释中的传播参数？

基本上什么时候以及为什么我应该选择更改它们的默认值？

Answer 1

好问题，尽管回答起来并不简单。

传播

定义如何传播交易是相互关联的。常见选项：

• REQUIRED：代码将始终在事务中运行。创建一项新事务或重用一项（如果可用）。
• REQUIRES_NEW：代码将始终在新事务中运行。如果存在当前事务，则暂停该事务。

@Transactional 的默认值是 REQUIRED，这通常是您想要的。

隔离

定义数据契约交易之间。

• ISOLATION_READ_UNCOMMITTED：允许脏读。
• ISOLATION_READ_COMMITTED：不允许脏读。
• ISOLATION_REPEATABLE_READ：如果在同一个事务中读取同一行两次，结果将始终相同。
• ISOLATION_SERIALIZABLE：按顺序执行所有事务。

在多线程应用程序中，不同级别具有不同的性能特征。我认为如果您理解脏读概念，您将能够选择一个好的选项。

不同数据库之间的默认值可能有所不同。例如，对于 MariaDB 它是可重复读取。

---

脏读何时可能发生的示例：

  thread 1   thread 2      
      |         |
    write(x)    |
      |         |
      |        read(x)
      |         |
    rollback    |
      v         v 
           value (x) is now dirty (incorrect)

因此，合理的默认值（如果可以声明的话）可以是 ISOLATION_READ_COMMITTED，它只允许您读取其他正在运行的事务已经提交的值，并结合传播级别为REQUIRED。然后，如果您的应用程序有其他需求，您可以从那里开始工作。

---

一个实际示例，说明在进入 provideService 例程时始终会创建新事务并在离开时完成：

public class FooService {
    private Repository repo1;
    private Repository repo2;

    @Transactional(propagation=Propagation.REQUIRES_NEW)
    public void provideService() {
        repo1.retrieveFoo();
        repo2.retrieveFoo();
    }
}

如果我们改为使用 REQUIRED，则事务 将保持打开状态。
另请注意，回滚的结果可能会有所不同，因为多个执行可能会参与同一事务。

---

我们可以通过测试轻松验证行为，并查看结果如何随传播级别的不同而变化：

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:/fooService.xml")
public class FooServiceTests {

    private @Autowired TransactionManager transactionManager;
    private @Autowired FooService fooService;

    @Test
    public void testProvideService() {
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
        fooService.provideService();
        transactionManager.rollback(status);
        // assert repository values are unchanged ... 
}

传播级别为

• REQUIRES_NEW 时：我们期望 fooService.provideService()由于创建了自己的子事务，因此未回滚。

• 必需：我们希望所有内容都回滚并且后备存储保持不变。

Answer 2

PROPAGATION_REQUIRED = 0；如果 DataSourceTransactionObject T1 已针对方法 M1 启动。如果需要另一个方法 M2 Transaction 对象，则不会创建新的 Transaction 对象。 M2 使用相同的对象 T1。

PROPAGATION_MANDATORY = 2；方法必须在事务内运行。如果没有
现有事务正在进行中，将抛出异常。

PROPAGATION_REQUIRES_NEW = 3；如果 DataSourceTransactionObject T1 已针对方法 M1 启动并且正在进行中（执行方法 M1）。如果另一个方法 M2 开始执行，则 T1 在方法 M2 的持续时间内暂停，并为 M2 提供新的 DataSourceTransactionObject T2。 M2 在其自己的事务上下文中运行。

PROPAGATION_NOT_SUPPORTED = 4；如果 DataSourceTransactionObject T1 已针对方法 M1 启动。如果同时运行另一个方法M2。那么 M2 不应该在事务上下文中运行。 T1 暂停，直到 M2 完成。

PROPAGATION_NEVER = 5；这些方法都没有在事务上下文中运行。

---

隔离级别：
它是关于一个事务可能受到其他并发事务的活动影响的程度。它支持一致性，使多个表中的数据保持一致状态。它涉及锁定数据库中的行和/或表。

多笔交易的问题

场景1。如果 T1 事务从表 A1 中读取由另一个并发事务 T2 写入的数据。如果途中T2回滚，则T1获取到的数据是无效的。例如a=2是原始数据。如果T1读取到T2写入的a=1。如果T2回滚，那么a=1将回滚到DB中的a=2。但是，现在T1的a=1，但在DB表中它被更改为a=2。

场景2。如果T1事务从表A1读取数据。如果另一个并发事务（T2）更新表A1上的数据。那么T1读取到的数据为
与表A1不同。因为T2已经更新了表A1上的数据。例如，如果 T1 读取 a=1 并且 T2 更新 a=2。那么a!=b。

场景 3。如果T1事务从表A1中读取一定行数的数据。如果另一个并发事务 (T2) 在表 A1 上插入更多行。这
T1 读取的行数与表 A1 上的行数不同。

场景 1 称为“脏读”。

场景 2 称为“不可重复读”。

场景 3 称为“幻读”。

因此，隔离级别是延伸到可以预防场景1、场景2、场景3。
您可以通过实现锁定来获得完全的隔离级别。这可以防止发生对同一数据的并发读取和写入。但它影响性能。隔离级别取决于应用程序之间需要多少隔离。

ISOLATION_READ_UNCOMMITTED：允许读取尚未提交的更改。它受到场景 1、场景 2、场景 3 的影响。

ISOLATION_READ_COMMITTED：允许从已提交的并发事务中读取。它可能会受到场景2和场景3的影响。因为其他事务可能正在更新数据。

ISOLATION_REPEATABLE_READ：同一字段的多次读取将产生相同的结果，直到它自行更改。它可能会遇到场景 3 的情况。因为其他事务可能正在插入数据。

ISOLATION_SERIALIZABLE：场景 1、场景 2、场景 3 永远不会发生。这是完全的隔离。它涉及完全锁定。由于锁定，它会影响性能。

您可以使用以下方式进行测试：

public class TransactionBehaviour {
   // set is either using xml Or annotation
    DataSourceTransactionManager manager=new DataSourceTransactionManager();
    SimpleTransactionStatus status=new SimpleTransactionStatus();
    
    public void beginTransaction() {
        DefaultTransactionDefinition Def = new DefaultTransactionDefinition();
        // overwrite default PROPAGATION_REQUIRED and ISOLATION_DEFAULT
        // set is either using xml Or annotation
        manager.setPropagationBehavior(XX);
        manager.setIsolationLevelName(XX);
       
        status = manager.getTransaction(Def);
    }

    public void commitTransaction() {
       
        if(status.isCompleted()) {
            manager.commit(status);
        } 
    }

    public void rollbackTransaction() {
       
        if(!status.isCompleted()) {
            manager.rollback(status);
        }
    }
    Main method {
        beginTransaction();
        M1();
        If error(){
            rollbackTransaction();
        }
        commitTransaction();
    }
   
}

您可以使用不同的隔离和传播值进行调试并查看结果。

Answer 3

其他答案给出了有关每个参数的足够解释；但是，您要求提供一个真实世界的示例，以下示例阐明了不同传播选项的目的：

Suppose you're in charge of implementing a signup service in which a confirmation e-mail is sent to the user. You come up with two service objects, one for enrolling the user and one for sending e-mails, which the latter is called inside the first one. For example something like this:

/* Sign Up service */
@Service
@Transactional(Propagation=REQUIRED)
class SignUpService{
 ...
 void SignUp(User user){
    ...
    emailService.sendMail(User);
 }
}

/* E-Mail Service */
@Service
@Transactional(Propagation=REQUIRES_NEW)
class EmailService{
 ...
 void sendMail(User user){
  try{
     ... // Trying to send the e-mail
  }catch( Exception)
 }
}

您可能已经注意到，第二个服务属于传播类型 REQUIRES_NEW，而且它很可能会引发异常（SMTP 服务器关闭、电子邮件无效或其他原因）。您可能不希望整个过程回滚，例如从数据库或其他内容中删除用户信息；因此，您可以在单独的事务中调用第二个服务。

Back to our example, this time you are concerned about the database security, so you define your DAO classes this way:

/* User DAO */
@Transactional(Propagation=MANDATORY)
class UserDAO{
 // some CRUD methods
}

这意味着每当创建 DAO 对象以及对数据库的潜在访问时，我们都需要确保该调用是从我们的一项服务内部进行的，这意味着应该存在实时事务；否则会出现异常。因此传播的类型是强制。

Answer 4

以下定义来自 byteslounge.com 教程 1 和 2 ：

隔离级别定义一个事务对某些数据存储库所做的更改如何影响其他同时并发的事务
事务，以及更改后的数据如何以及何时变为
可用于其他交易。当我们定义一个事务时使用
Spring框架我们还可以配置隔离
将执行相同交易的级别。

@Transactional(isolation=Isolation.READ_COMMITTED)
公共无效 someTransactionalMethod（对象 obj）{

}

READ_UNCOMMITTED 隔离级别表明事务可以读取
其他事务尚未提交的数据。

READ_COMMITTED 隔离级别表明事务无法读取
其他事务尚未提交的数据。

REPEATABLE_READ 隔离级别规定如果一个事务读取一个
从数据库中多次记录所有这些结果
读取操作必须始终相同。

SERIALIZABLE 隔离级别是所有隔离中限制最严格的
水平。事务在所有级别（读、
范围和写锁定），因此它们看起来就像是在一个
序列化方式。

传播是决定如何将业务方法封装在逻辑或物理事务中的能力。

Spring REQUIRED 行为意味着将使用相同的事务
如果当前bean方法中有一个已经打开的事务
执行上下文。

REQUIRES_NEW 行为意味着新的物理事务将
始终由容器创建。

NESTED 行为使得嵌套 Spring 事务使用相同的
物理事务，但在嵌套调用之间设置保存点，以便
内部事务也可以独立于外部事务回滚
交易。

强制行为规定现有已打开的事务必须
已经存在。如果不是，容器将抛出异常。

NEVER 行为表明现有已打开的事务不得
已经存在。如果事务存在，则会抛出异常
容器。

NOT_SUPPORTED 行为将在任何范围之外执行
交易。如果打开的交易已经存在，它将是
暂停。

SUPPORTS 行为将在事务范围内执行，如果
打开的交易已经存在。如果没有已经打开的
事务 该方法无论如何都会执行，但在非事务中
方式。

Answer 5

事务代表数据库的一个工作单元。

事务传播：Spring 允许您指定事务如何在方法调用和嵌套事务之间传播。

事务隔离：Spring允许您指定事务的隔离级别，这样您就可以确保它们与其他并发事务隔离。

在 spring TransactionDefinition 接口中，定义了 Spring 兼容的事务属性。 @Transactional 注解描述了方法或类的事务属性。

@Autowired
private TestDAO testDAO;

@Transactional(propagation=TransactionDefinition.PROPAGATION_REQUIRED,isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED)
public void someTransactionalMethod(User user) {

  // Interact with testDAO

}

---

传播（复制）：用于事务间关系。 （类似于java线程间通信）

+-------+---------------------------+------------------------------------------------------------------------------------------------------+
| value |        Propagation        |                                             Description                                              |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+
|    -1 | TIMEOUT_DEFAULT           | Use the default timeout of the underlying transaction system, or none if timeouts are not supported. |
|     0 | PROPAGATION_REQUIRED      | Support a current transaction; create a new one if none exists.                                      |
|     1 | PROPAGATION_SUPPORTS      | Support a current transaction; execute non-transactionally if none exists.                           |
|     2 | PROPAGATION_MANDATORY     | Support a current transaction; throw an exception if no current transaction exists.                  |
|     3 | PROPAGATION_REQUIRES_NEW  | Create a new transaction, suspending the current transaction if one exists.                          |
|     4 | PROPAGATION_NOT_SUPPORTED | Do not support a current transaction; rather always execute non-transactionally.                     |
|     5 | PROPAGATION_NEVER         | Do not support a current transaction; throw an exception if a current transaction exists.            |
|     6 | PROPAGATION_NESTED        | Execute within a nested transaction if a current transaction exists.                                 |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+

---

隔离性：隔离性是数据库事务的 ACID（原子性、一致性、隔离性、持久性）属性之一。隔离性决定了事务完整性如何对其他用户和系统可见。它用于资源锁定，即并发控制，确保在给定点只有一个事务可以访问资源。

锁定感知：隔离级别决定了锁定的持续时间。

+---------------------------+-------------------+-------------+-------------+------------------------+
| Isolation Level Mode      |  Read             |   Insert    |   Update    |       Lock Scope       |
+---------------------------+-------------------+-------------+-------------+------------------------+
| READ_UNCOMMITTED (Low)    |  uncommitted data | Allowed     | Allowed     | No Lock                |
| READ_COMMITTED (Default)  |   committed data  | Allowed     | Allowed     | Lock on Committed data |
| REPEATABLE_READ           |   committed data  | Allowed     | Not Allowed | Lock on block of table |
| SERIALIZABLE (High)       |   committed data  | Not Allowed | Not Allowed | Lock on full table     |
+---------------------------+-------------------+-------------+-------------+------------------------+

读感知：会出现以下3种主要问题：

• 脏读：从另一个tx（事务）中读取未提交的数据。
• 不可重复读取：从另一个交易读取已提交的UPDATES。
• 幻读：从另一个交易中读取提交的INSERTS和/或DELETES

下面的图表显示了哪种事务隔离级别解决了哪些并发问题：

+---------------------------+--------------+----------------------+----------------+
| Isolation Level Mode      |  Dirty reads | Non-repeatable reads | Phantoms reads |
+---------------------------+--------------+----------------------+----------------+
| READ_UNCOMMITTED          | X            | X                    | X           |
| READ_COMMITTED (Default)  | solves       | X                    | X           |
| REPEATABLE_READ           | solves       | solves               | X           |
| SERIALIZABLE              | solves       | solves               | solves      |
+---------------------------+--------------+----------------------+----------------+

示例

Answer 6

您几乎永远不想使用Read Uncommited，因为它并不真正符合ACID。 Read Commmited 是一个很好的默认起点。 可重复读取可能只在报告、汇总或聚合场景中需要。请注意，许多数据库（包括 postgres）实际上并不支持可重复读取，您必须使用 Serialized 代替。 Serialized 对于您知道必须完全独立于其他任何事情发生的事情很有用；可以将其想象为 Java 中的同步。可序列化与 REQUIRES_NEW 传播密切相关。

我将 REQUIRES 用于运行 UPDATE 或 DELETE 查询以及“服务”级别函数的所有函数。对于仅运行 SELECT 的 DAO 级别函数，我使用 SUPPORTS ，如果该函数已经启动（即从服务函数调用），它将参与 TX。

Answer 7

事务隔离和事务传播虽然相关，但显然是两个截然不同的概念。在这两种情况下，默认值都是通过使用 声明式事务管理 或 程序化交易管理。每个隔离级别和传播属性的详细信息可以在下面的参考链接中找到。

事务隔离

对于给定的两个或多个正在运行的事务/与数据库的连接，一个事务中的查询所做的更改如何以及何时对另一事务中的查询产生影响/可见。它还涉及使用哪种数据库记录锁定来将该事务中的更改与其他事务隔离开来，反之亦然。这通常由参与事务的数据库/资源​​来实现。

。

事务传播

在企业应用程序中针对任何给定的请求/处理过程涉及许多组件来完成工作。其中一些组件标记了将在相应组件及其子组件中使用的事务的边界（开始/结束）。对于组件的事务边界，事务传播指定相应组件是否将参与事务，以及如果调用组件已经或没有已创建/启动的事务，会发生什么情况。这与 Java EE 事务属性相同。这通常由客户端事务/连接管理器实现。

参考：

• Spring 事务管理

• <一个href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29">Wiki 事务隔离（数据库系统）

• Oracle 的事务隔离级别

• Java EE 事务属性（传播）

• Spring 框架事务传播

Answer 8

我已经使用不同的传播模式运行了 outerMethod、method_1 和 method_2。

以下是不同传播模式的输出。

外部方法

    @Transactional
    @Override
    public void outerMethod() {
        customerProfileDAO.method_1();
        iWorkflowDetailDao.method_2();
    }

Method_1

    @Transactional(propagation=Propagation.MANDATORY)
    public void method_1() {
        Session session = null;
        try {
            session = getSession();
            Temp entity = new Temp(0l, "XXX");
            session.save(entity);
            System.out.println("Method - 1 Id "+entity.getId());
        } finally {
            if (session != null && session.isOpen()) {

            }
        }
    }

Method_2

    @Transactional()
    @Override
    public void method_2() {
        Session session = null;
        try {
            session = getSession();
            Temp entity = new Temp(0l, "CCC");
            session.save(entity);
            int i = 1/0;
            System.out.println("Method - 2 Id "+entity.getId());
        } finally {
            if (session != null && session.isOpen()) {

            }
        }
    }

1. • OuterMethod - 无事务
   • 方法_1 - 传播。强制）-
   • Method_2 - 仅交易注释
   • 输出：method_1 将抛出没有现有事务的异常

---

2. • OuterMethod - 无事务
   • Method_1 - 仅交易注释
   • 方法_2 - 传播。强制）
   • 输出：method_2 将抛出没有现有事务的异常
   • 输出：method_1 将在数据库中保留记录。

---

3. • OuterMethod - 带事务
   • Method_1 - 仅交易注释
   • 方法_2 - 传播。强制）
   • 输出：method_2 将在数据库中保留记录。
   • 输出：method_1 将在数据库中保留记录。
     -- 这里主要外部现有事务用于方法 1 和 2

---

4. • OuterMethod - 带事务
   • 方法_1 - 传播。强制）
   • Method_2 - 仅事务注释并引发异常
   • 输出：数据库中没有记录持久意味着回滚已完成。

---

5. • OuterMethod - 带事务
   • 方法_1 - 传播。REQUIRES_NEW)
   • Method_2 - Propagation.REQUIRES_NEW) 并引发 1/0 异常
   • 输出：method_2 将引发异常，因此 method_2 记录不会保留。
   • 输出：method_1 将在数据库中保留记录。
   • 输出：method_1 没有回滚

Answer 9

我们可以为此添加：

@Transactional(readOnly = true)
public class Banking_CustomerService implements CustomerService {

    public Customer getDetail(String customername) {
        // do something
    }

    // these settings have precedence for this method
    @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
    public void updateCustomer(Customer customer) {
        // do something
    }
}

Answer 10

你可以这样使用：

@Transactional(propagation = Propagation.REQUIRES_NEW)
public EventMessage<ModificaOperativitaRapporto> activate(EventMessage<ModificaOperativitaRapporto> eventMessage) {
//here some transaction related code
}

你也可以使用这个东西：

public interface TransactionStatus extends SavepointManager {
    boolean isNewTransaction();
    boolean hasSavepoint();
    void setRollbackOnly();
    boolean isRollbackOnly();
    void flush();
    boolean isCompleted();
}