hibernate - JPA : applicationManaged EntityManager for Java SE to control transaction lifecycle programmatically

Question

我很难找到一个好的解决方案来支持 UI 可以启动和提交事务的此功能。

在我以前处理事务性应用程序的方法中，我将工作单元分组到后端中的服务方法中，并使用 spring 的@Transactional 对其进行注释。

---

但想象一下，我有几个这样的服务方法，由前端在事务中对服务方法调用进行分组。

例如，我有 methodServiceA、methodServiceB、methodServiceC。用户界面可以通过以下任何组合来执行类似的操作:

组合 1:

1. 开始交易
2. 调用方法ServiceA + 调用方法ServiceB
3. 提交交易

组合二:

1. 开始交易
2. 调用方法ServiceB + 调用方法ServiceC
3. 提交交易

组合三:

1. 开始交易
2. 调用方法ServiceA + 调用方法ServiceB + 调用方法ServiceC
3. 提交交易

基本上，后端只提供服务方法，由 UI 或其他应用程序使用后端来启动/提交事务。

---

这基本上就是我正在处理的情况.. 这就是我的想法。请分享一些其他选项或者我可以做的改进以支持此功能。我目前正在考虑使用应用程序管理的实体管理器，因为我认为在这种情况下使用@Transactional 是行不通的。

我正在考虑 UI 或其他连接器可用于的对象:

1. 创建实体管理器并将其与唯一 ID 相关联
2. 从 em 开始交易
3. 设置超时时间
4. 从 em 提交事务
5. 如果 em 有任何异常，自动回滚事务
6. 将事务的实体管理器提供给服务方法，以便它们使用相同的实体管理器
7. 在从 em 提交或回滚后最终关闭实体管理器

因此，对于组合 1 的示例，流程是这样的:

1. ui 使用工具启动事务，并获取entitymanager id
2. 在调用 methodServiceA + 调用 methodServiceB 时传递 entitymanager id，因此这些方法可以使用与 id 关联的正确实体管理器
3. 提交交易

---

请分享您对此事的看法，谢谢!

---

关于外观/命令模式:

谢谢你的想法。但我也考虑过这一点，我认为它不适合我们的需求，因为我不能总是在后端提供外观服务来满足出现的每一个需求(想象一下每个 ui 按钮都可以组合他们想要的任何方法服务)。

基本思想是拥有其他前端应用程序可以连接在一起的公共(public)服务方法。

而且，使用外观模式意味着外观方法中没有 ui 逻辑。在我们的例子中，ui 逻辑可以与前端的事务处理和调用服务方法一起完成。

Answer 1

使用外观模式:创建一个外观服务，其中包含每个组合的方法(应该映射到一个功能用例)，并使用 Spring 注释使这些外观方法具有事务性。外观方法将只调用现有的服务方法。