JPA：applicationManaged EntityManager for Java SE以编程方式控制事务生命周期

Question

我很难找到支持此功能的好解决方案，其中UI可以启动并提交事务。

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

---

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

例如，我有methodServiceA，methodServiceB，methodServiceC。 用户可以使用以下任意组合执行此类操作：

组合1：

1. 启动交易
2. 调用methodServiceA +调用methodServiceB
3. 提交交易

组合2：

1. 启动交易
2. 调用methodServiceB +调用methodServiceC
3. 提交交易

组合3：

1. 启动交易
2. 调用methodServiceA +调用methodServiceB +调用methodServiceC
3. 提交交易

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

---

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

我想到了UI或其他连接器可用于的对象：

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

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

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

---

请分享您对此事的想法，谢谢！

---

关于外观/命令模式：

感谢您的想法。但我也考虑过这一点，我认为它不适合我们的需求，因为我不能总是在后端提供外观服务，以满足每一个需求（想象一下可以结合他们想要的任何方法服务的每个UI按钮）。

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

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

Answer 1

使用外观模式：创建一个外观服务，其中包含每个组合的方法（应该映射一个功能用例），并使用Spring注释使这些外观方法成为事务性的。 facade方法只调用现有的服务方法。

Answer 2

您可以尝试使用Command pattern - UI发送一系列命令，您的后端在单个事务中执行它们。

或者，看看extended persistence context的概念 - 它类似于您提出的方法，但在这种情况下，步骤不会共享相同的事务。或许对你的一些想法与你的情况有关。