交易传播的现实场景

Question

有各种交易传播，例如

REQUIRED- 这是DML操作的情况。

SUPPORTS- 这是查询数据库的情况。

MANDATORY - ?
REQUIRES_NEW - ?
NOT_SUPPORTED - ?
NEVER - ?
NESTED - ?

这些交易传播的现实生活场景有哪些？为什么这些非常适合这种情况？

Answer 1

有多种用法，没有简单的答案，但我会尽力解释得最清楚

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

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

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

• 必需：无->T1，T1->T1
• REQUIRES_NEW：无->T1，T1->T2
• 强制：无->异常，T1->T1
• NOT_SUPPORTED：无->无，T1->无
• 支持：无->无，T1->T1
• 从不：无->无，T1->异常