Question

有各种交易传播，如

SUPPORTS - 这是DML操作的情况。

MANDATORY - ? REQUIRES_NEW - ? NOT_SUPPORTED - ? NEVER - ? NESTED - ? - 这是查询数据库的情况。

mainobj {
    properties:{
        elem:{
            $form:'referencetoDOMForm',
            $table: 'referncetoTableElement'
            $tab: 'referencetoDivElement',
            ...
             },
        $html_main:'referencetomainDOM',
        otherprops:{ ...},
        ...
      }
}

使用这些事务传播的一些真实场景是什么？为什么这些完全符合这种情况？

Answer 1

有各种各样的用法，没有简单的答案，但我会尝试成为最具说明性的

强制性（期待交易）：通常在您希望任何“更高上下文”层启动交易并且您只想继续进行交易时使用。例如，如果您希望从HTTP请求到响应的整个操作有一个事务。然后在JAX-RS资源级别启动事务，而较低层（服务）要求事务在其中运行（否则抛出异常）。
REQUIRES_NEW（始终创建新事务）：这会创建一个新事务并暂停当前事务（如果存在）。从上面的示例中，这是您在JAX-RS资源上设置的级别，例如。或者通常，如果您的流程以某种方式更改并且您希望将逻辑拆分为多个事务（因此您的代码具有应该分离的多个逻辑操作）。
必需（在交易中继续或在需要时创建）：MANDATORY和REQUIRES_NEW之间的某种混合。在MANDATORY中，您希望事务存在，对于此级别，您希望它存在，如果不存在，则创建它。通常用于DAO类服务（根据我的经验），但它实际上取决于您的应用程序的逻辑。
SUPPORTS（调用者决定是否不在事务中运行）：如果想要使用与调用者相同的上下文（更高的上下文），如果调用者在事务中运行，则运行，然后运行太。如果没有，您也是非交易性的。如果您想要更高的上下文来决定，也可以在类似DAO的服务中使用。
NESTED（子事务）：我必须承认我没有在实际代码中使用这个，但通常你创建一个真正的子事务，作为某种检查点。所以它在“父”事务的上下文中运行但如果失败则返回到该检查点（嵌套事务的开始）。当您在应用程序中需要这种逻辑时，这可能很有用，例如，如果您要将大量项目插入数据库，提交有效项目并跟踪无效项目（因此您可以在嵌套事务失败时捕获异常但是仍然可以提交有效的整个交易）
从不（期待没有交易）：当您想要确保根本不存在任何交易时就是这种情况。如果在事务中运行的某些代码到达此代码，则抛出异常。所以通常这适用于与MANDARTORY完全相反的情况。例如。当你知道这个代码不应该影响任何交易时 - 很可能因为交易不应该存在。
NOT_SUPPORTED（非事务性地继续）：这比从不弱，您希望代码以非事务方式运行。如果以某种方式从事务所在的上下文输入此代码，则暂停此事务并以非事务方式继续。

根据我的经验，您经常希望一个商业行为是原子的。因此，每个请求只需要一个事务/ ...例如，通过HTTP进行简单的REST调用，在一个类似HTTP的事务中执行一些数据库操作。所以我的典型用法是在顶级（JAX-RS资源） REQUIRES_NEW 和注入此资源（甚至更低）的所有较低级别服务上的 MANDATORY 。

这可能对您有用。它描述了代码在给定传播时的行为（调用者 - >方法）

需要：NONE-＆gt; T1，T1-＆gt; T1
REQUIRES_NEW ：NONE-＆gt; T1，T1-＆gt; T2
MANDATORY ：NONE-＆gt;例外，T1-＆gt; T1
NOT_SUPPORTED ：NONE-＆gt; NONE，T1-＆gt; NONE
支持：NONE-＆gt; NONE，T1-＆gt; T1
从不：NONE-＆gt; NONE，T1-＆gt;例外

事务传播的真实场景

1 个答案: