JPA事务范围EntityManager vs扩展范围：为何不选有状态Bean的扩展范围？

我们的Web应用采用EclipseLink作为JPA实现，目前在无状态Bean中使用事务范围（JTA事务类型）的EntityManager——这是常规推荐用法，但测试中发现同一方法内两次调用entityManager.find(class, id)会返回不同对象，且事务范围EntityManager对应独立事务，内存消耗更高。现在想改为在有状态Bean中使用扩展范围的EntityManager，以下是相关问题的解答：

一、为何常规场景不推荐使用扩展范围EntityManager？ #

无状态Bean是容器管理的实例池，轻量可复用，而有状态Bean绑定单个客户端，实例无法复用，本身就会增加容器资源开销。扩展范围的EntityManager生命周期与有状态Bean绑定，会长期持有实体对象引用，容易引发一系列隐性问题，所以非特定场景下不推荐。

二、该方案的优势 #

• 一级缓存复用：同一有状态Bean实例的多次方法调用（甚至跨事务）会复用同一个EntityManager的一级缓存，同一find()调用返回同一个对象实例，避免重复查询和对象重复创建，降低内存开销与数据库访问次数。
• 跨事务状态管理：可在多个事务间保持实体的托管状态，比如在一个事务加载实体、修改后，另一个事务直接提交，无需重新查询，适合长会话交互场景（如分步提交的表单流程）。
• 简化代码逻辑：扩展EntityManager的实体始终处于托管状态，跨事务操作时无需手动调用merge()，减少代码复杂度。

三、会引发的问题 #

• 高资源占用：每个客户端绑定一个有状态Bean实例和对应的EntityManager，加上一级缓存中的实体，高并发场景下会导致内存飙升，容器负载剧增。
• 数据一致性风险：扩展EntityManager的生命周期跨多个事务，若某事务回滚后缓存脏数据未清理，后续操作会使用错误的实体状态，引发数据不一致。
• 并发安全问题：EntityManager本身非线程安全，若客户端多线程调用同一个有状态Bean实例，会触发并发访问异常。
• 容器管理复杂度提升：有状态Bean的销毁、钝化/激活逻辑更复杂，EntityManager钝化时需处理缓存序列化，若实体包含不可序列化属性，会导致序列化失败。
• 内存泄漏风险：若有状态Bean实例未被正确销毁（如客户端断开后容器未及时回收），EntityManager和缓存实体将长期占用内存，引发泄漏。

当前事务范围EntityManager代码 #

@Stateless
@LocalBean
public class SessionBean{
    @PersistenceContext(unitName = "name", type = PersistenceContextType.TRANSACTION)
    EntityManager entityManager;
}

拟修改的扩展范围EntityManager代码 #

@Stateful
@LocalBean
public class SessionBean{
    @PersistenceContext(unitName = "name", type = PersistenceContextType.EXTENDED)
    EntityManager entityManager;
}

内容的提问来源于stack exchange，提问作者bill tsi