Java EE 应用程序服务器中通过 CDI 中的 @PersistenceContext 获得的 EntityManager 是线程安全的吗？答案

【问题标题】：Is EntityManager obtained via @PersistenceContext in CDI in Java EE application server thread-safe?Java EE 应用程序服务器中通过 CDI 中的 @PersistenceContext 获得的 EntityManager 是线程安全的吗？
【发布时间】：2018-10-01 17:21:06
【问题描述】：

我知道自己实例化的EntityManager不是线程安全的。
我知道在 EJB 中通过 @PersistenceContext 注入的 EntityManager 的行为类似于线程安全，因为 EJB 容器序列化了对 EJB bean 的访问。
我知道在 EJB 中注入的EntityManager 确实是一个代理。
我知道，当我通过@PersistenceContext 将EntityManager 注入到@Dependent CDI bean 并将该bean 注入到EJB 时，它的行为就像是线程安全的，因为它覆盖了EJB（我相信在这种情况下EntityManager 是代理）。

但是：

当我通过@PersistenceContext 将EntityManager 注入CDI bean 并直接在Servlet 中使用这个bean 时会发生什么？我相信这个EntityManager是一个代理，那么这个代理能保证线程安全吗？

编辑：类似的问题 Java CDI @PersistenceContext and thread safety 不能解决我的问题，因为接受的答案显示的是 EJB 示例，而不是 CDI 示例。

编辑：我检查了 WildFly 应用服务器的源代码，它看起来 WildFly 在 CDI 中使用了线程安全代理。此代理在需要时选择真正的 EntityManager。真正的 EntityManager 保存在特殊的结构中 - ThreadLocal 中的 EntityManager 映射堆栈。

【问题讨论】：

Java CDI @PersistenceContext and thread safety的可能重复
看看那个链接对你有没有帮助！
@JGlass，这个链接不能解决我的问题，因为接受的答案显示的是 EJB 示例，而不是 CDI 示例。
他们让它看起来不管 EJB 还是 CDI - 它都不是线程安全的。另一个问题上的 OP 确实说明了您所做的相同问题 - 我认为它们只是与 EJB 相关而不是 CDI 但仍然相关的示例？
不，CDI 与 EJB 不同。

标签： jpa jakarta-ee thread-safety ejb cdi

【解决方案1】：

https://www.javacodegeeks.com/2013/06/jpa-2-entitymanagers-transactions-and-everything-around-it.html 说：

使用 Transaction Scoped Entity Manager 的最大好处是它是无国籍的。这也使得 Transaction Scoped EntityManager 线程安全，因此几乎免维护

还有专业的 JPA 书说：

事务范围的实体管理器是无状态的，这意味着它可以安全地存储在任何 Java EE 组件上

【讨论】：