Spring @事务性-隔离、传播

Propagation_required = 0;如果方法M1的DataSourceTransactionObject T1已经启动。如果需要另一个Method M2事务对象，则不创建新的事务对象。同样的对象T1用于M2。

Propagation_mandatory = 2;方法必须在事务中运行。如果没有现有事务正在进行中，将引发异常。

Propagation_requires_new = 3;如果DataSourceTransactionObject T1已经为方法M1启动，并且正在进行中(执行方法M1)。如果另一个方法M2开始执行，那么T1将在方法M2的持续时间内挂起，并为M2创建新的DataSourceTransactionObject T2。M2在它自己的事务上下文中运行。

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

Propagation_never = 5;没有一个方法在事务上下文中运行。

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

多重事务的问题

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

Scenario2。如果T1事务从表A1读取数据。如果另一个并发事务(T2)更新表A1上的数据。那么T1读取的数据是不同于表格A1。因为T2更新了表A1上的数据。例如，如果T1读取a=1, T2更新a=2。然后一个! = b。

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

场景1称为脏读。

场景2称为不可重复读取。

场景3被称为幻影读取。

因此，隔离级别是可以防止场景1、场景2、场景3的扩展。您可以通过实现锁定来获得完整的隔离级别。这阻止了对同一数据的并发读写。但它会影响性能。隔离级别取决于应用程序与应用程序之间所需的隔离程度。

ISOLATION_READ_UNCOMMITTED:允许读取尚未提交的更改。它遭受场景一，场景二，场景三。

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();
    }
   
}

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

2013-04-22 16:10:32

好问题，虽然不是一个微不足道的问题。

传播

定义事务如何相互关联。常见的选项:

REQUIRED:代码总是在事务中运行。创建一个新的事务或重用一个可用的事务。 REQUIRES_NEW:代码总是在一个新的事务中运行。如果存在当前事务，则暂停当前事务。

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

隔离

定义事务之间的数据契约。

ISOLATION_READ_UNCOMMITTED:允许脏读。 ISOLATION_READ_COMMITTED:不允许脏读。 ISOLATION_REPEATABLE_READ:如果在同一个事务中读取一行两次，结果总是相同的。 ISOLATION_SERIALIZABLE:按顺序执行所有事务。

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

缺省值在不同数据库之间可能有所不同。例如，对于MariaDB，它是REPEATABLE READ。

可以发生脏读的示例:

  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()没有回滚，因为它创建了自己的子事务。 REQUIRED:我们期望所有东西都回滚了，备份存储没有改变。

2011-12-13 14:34:20

我已经用不同的传播模式运行了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()) {

            }
        }
    }

OuterMethod -没有事务传播。mandatory) - Method_2 -仅事务注释 method_1将抛出不存在事务的异常

OuterMethod -没有事务 Method_1 -仅事务注释方法2 -传播。mandatory) 输出:method_2将抛出不存在事务的异常输出:method_1将保存数据库中的记录。

OuterMethod -带有事务 Method_1 -仅事务注释方法2 -传播。mandatory) 输出:method_2将记录保存在数据库中。输出:method_1将保存数据库中的记录。方法1和方法2都使用了Main Outer现有事务

OuterMethod -带有事务传播。mandatory) Method_2 -仅事务注释并抛出异常输出:没有记录保存在数据库中意味着回滚完成。

OuterMethod -带有事务方法1 -传播。requires_new) Method_2 - Propagation.REQUIRES_NEW)并抛出1/0异常输出:method_2将抛出异常，因此method_2记录不被保存。输出:method_1将保存数据库中的记录。输出:method_1没有回滚

2015-08-26 10:04:19

You almost never want to use Read Uncommited since it's not really ACID compliant. Read Commmited is a good default starting place. Repeatable Read is probably only needed in reporting, rollup or aggregation scenarios. Note that many DBs, postgres included don't actually support Repeatable Read, you have to use Serializable instead. Serializable is useful for things that you know have to happen completely independently of anything else; think of it like synchronized in Java. Serializable goes hand in hand with REQUIRES_NEW propagation.

我对所有运行UPDATE或DELETE查询的函数以及“服务”级函数都使用require。对于只运行select的DAO级函数，我使用SUPPORTS，如果一个已经启动(即从服务函数调用)，它将参与TX。

2011-12-13 15:13:14