JPA：applicationManaged EntityManager for Java SE以编程方式控制事务生命周期 [英] JPA : applicationManaged EntityManager for Java SE to control transaction lifecycle programmatically

问题描述

在我以前使用事务性应用程序的方法中，我很难找到一个很好的解决方案来支持此功能。 ，我将工作单元分组到后端中的服务方法中，并使用spring的@Transactional对其进行注释。

---

但假设我有这样的几种服务方法，它取决于前端将事务中的服务方法调用分组。

例如，我有methodServiceA，methodServiceB，methodServiceC。
UI可以通过以下任何组合来做到这一点：

组合1：

1. 启动交易


2. 调用methodServiceA +调用methodServiceB


3. 提交交易
   

组合2：

1. 开始交易


2. call methodServiceB + call methodServiceC


3. 提交交易

组合3：

$ b

1. 开始交易


2. 调用methodServiceA +调用methodServiceB +调用methodServiceC


3. 提交事务

基本上，后端只提供服务方法，取决于使用UI或其他应用程序后端开始/提交交易。

---

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

我想到一个对象，即UI或其他连接器可以用来：

1. 创建一个实体管理器，并将其与一个唯一的ID关联起来


2. 开始从


3. 设置超时


4. 自动从em


5. 如果有任何异常，则回滚事务


6. 将事务的实体管理器提供给服务方法，以便它们使用相同的实体管理器


7. 最后在提交或回滚之后关闭实体管理器

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

1. ui使用该工具启动事务，并获取entitymanager id


2. 传递entitymanager id w hile调用methodServiceA +调用methodServiceB，因此这些方法可以使用与id关联的正确实体管理器。


3. 提交事务

---

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

---

关于外观/命令模式：

感谢您的想法。但是我也考虑过这个问题，我不认为它适合我们的需求，因为我无法总是在后端为每个需求提供门面服务（想象每个可以组合任何方法服务的UI按钮）。

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

另外，使用facade模式意味着facade方法中没有ui逻辑。在我们的例子中，ui逻辑可以与事务处理一起完成，并调用前端的服务方法。 可以尝试使用命令模式 - UI发送一系列命令，并且后端在其中执行它们一个单一的交易。

或者，看看扩展持久化上下文 - 这与您提出的方法类似，但在这种情况下，步骤不会共享相同的事务。或许你的想法与你的情况有关。

I'm having difficulties finding a good solution to support this feature where the UI can start and commit the transaction.

In my previous approaches in working with transactional applications, i group the unit of work into a service method in the backend, and annotate it with spring's @Transactional.

---

But imagine that i have several service methods like this, and it's up to the frontend to group the service method calls within a transaction.

For example, i have methodServiceA, methodServiceB, methodServiceC. The UI could do something like this with any combinations like :

Combination 1 :

1. starts the transaction
2. call methodServiceA + call methodServiceB
3. commits the transaction

Combination 2 :

1. starts the transaction
2. call methodServiceB + call methodServiceC
3. commits the transaction

Combination 3 :

1. starts the transaction
2. call methodServiceA + call methodServiceB + call methodServiceC
3. commits the transaction

Basically, the backend provides only the services method, and it's up to the UI or other applications that make use of the backend to start / commit the transaction.

---

So that is basically the situation i'm dealing with .. and here's the thing i have in mind. Please share some other options or perhaps improvements i could make to support this feature. Im currently thinking of using the application managed entitymanager, since i dont think using the @Transactional would work in this case.

Im thinking of an object that the UI or other connectors could use to :

1. create an entity manager and associates it with a unique id
2. start the transaction from the em
3. set the timeout from the em
4. commit the transaction from the em
5. automatically rollback the transaction if there're any exceptions from the em
6. feeds the transaction's entity manager to the service methods, so that they use the same entity manager
7. finally closes the entity manager after commit or rollback from the em

So, for the example for Combination 1, the flow is something like this :

1. ui starts the transaction using the tool, and get the entitymanager id
2. pass the entitymanager id while calling methodServiceA + calling methodServiceB, so those methods could use the correct entity manager which is associated with the id
3. commits the transaction

---

Please share your ideas on this matter, Thank you !

---

Concerning the facade / command pattern :

Thanks for the idea. But i've thought about this also, and i dont think it's suitable for our needs since i cant always provide the facade service in the backend for every needs(imagine every ui buttons that can combine any method services that they want) that arise.

The basic idea is to have public service methods that other frontend applications could wire together.

And also, using the facade pattern means no ui logic in the facade method. In our case, the ui logic can be done along with the transaction handling and calling the service methods in the frontend.

解决方案

You can try to use a Command pattern - UI sends a sequence of commands, and your backend executes them in a single transaction.

Alternatively, take a look at the concept of extended persistence context - it's something similar to your proposed approach, though in that case steps don't share the same transaction. Perhaps some thoughts regarding it would be relevant in your case.

这篇关于JPA：applicationManaged EntityManager for Java SE以编程方式控制事务生命周期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！