Spring事务中require_new和嵌套传播之间的区别
我无法理解PROPAGATION_REQUIRES_NEW和PROPAGATION_NESTED传播策略之间的行为差异。在我看来，在这两种情况下，当前过程都是回滚的，而不是整个事务。有什么线索吗？
问题答案：
看到此链接：PROPAGATION_NESTED与PROPAGATION_REQUIRES_NEW？Juergen
Hoeller对此进行了很好的解释。- 春季高峰论坛是完全脱机SICE 2019 2月28日，但你可以在下面的报价阅读文章的相关部分
PROPAGATION_REQUIRES_NEW为给定范围启动一个新的，独立的“内部”交易。此事务将完全独立于外部事务进行提交或回滚，具有自己的隔离范围，自己的一组锁等。外部事务将在内部事务的开始处挂起，并在内部事务具有完成。…
另一方面，PROPAGATION_NESTED启动“嵌套”事务，这是现有事务的真实子事务。将会发生的事情是，在嵌套事务开始时将获取一个保存点。如果嵌套事务失败，我们将回滚到该保存点。嵌套事务是外部事务的一部分，因此它将仅在外部事务的结尾提交。…
-
我有一个使用Hibernate/JPA的持久性Spring Boot应用程序。 我正在使用事务来管理我的数据库持久性，并且我正在使用注释来定义应该以事务方式执行的方法。 在持久化时，我有三个主要的事务粒度级别： 要保留的实体批次 要保留的单个实体 保留实体的单一数据库操作 因此，在考虑整个持久性流量时，您可以想象我有三个级别的嵌套事务。 第2层和第3层之间的交互如我所愿透明地工作，因为在没有为事务
-
我试图理解Spring事务概念。如下所示，我必须将数据插入两个不同的数据库（iSeries和DB2），但我们的iSeries版本不支持两阶段提交。要求是，只有当两个插入都成功时才应该提交事务，否则应该回滚。 如果我根据需要使用传播或REQUIRES\u NEW，我会得到错误“非法尝试使用现有的两阶段资源提交一阶段资源”。 但是如果我使用NOT_SUPPORTED或支持，它工作正常（即如果其中一个插
-
问题内容： 在我的应用程序中，有多个步骤，其中将通过多种方法对数据库进行多次提交。例： A呼叫B，再呼叫C。然后B呼叫D。D呼叫E，依此类推。所有这些方法都有一些数据库操作。据我了解（声明式事务管理- 春天推荐的方式），如果 E* 成功完成，则事务（以及 E中的 操作将被提交）。现在，由于某些例外， F 应该导致回滚。我想 从 A 做起的 所有事情都 回滚。是否可以通过声明式事务管理？还是应该使用
-
在下面的文章中说， 在此处输入链接描述 需要传播–支持当前交易；如果不存在，请创建一个新的。 下面是一个产品代码，然后是两个表的产品详细信息。 我的问题是什么时候会发生这种行为？我的意思是，当前交易怎么会结束？是在保存还是更新之后？ 如果我们使用PROPAGATION_REQUIRED假设当前事务在插入产品后结束。然后一个新的事务来了，但是如果插入产品数量时出现任何故障，它只会回滚数量而不是输入的
-
所称的刀是： 我希望服务类中的方法在事务中运行，并在方法出现异常时回滚所有内容。但这不是在事务中运行的。 如果我将添加到DAO方法中，那么它看起来就像是在单独的事务中运行的。这是正确的吗？
-
问题内容： 我知道这是一个重复的问题，但是我想以一种非常具体的方式提出这个问题，以阐明一个非常重要的观点。主要问题是：如果一个相同的类是静态嵌套类，而另一个是常规的顶层类，而不是访问包含类中的私有静态字段，则这些相同的类之间是否有任何区别？ 换句话说：可以直接访问的内容与可以直接访问的内容之间唯一唯一的区别是不能直接访问吗？还是存在其他通常不会讨论或遇到的细微差别？ 问题答案： 您的说法是正确的：