JPA 存储库应首选哪个 CDI 范围答案

【问题标题】：Which CDI scope should be preferred for a JPA repositoryJPA 存储库应首选哪个 CDI 范围
【发布时间】：2014-12-02 10:33:17
【问题描述】：

如何为如下所示的 JPA 存储库确定适当的 CDI 范围？

@Transactional
public class CategoryRep extends EntityRepository<Integer, Category> {

    private static final long serialVersionUID = 856370976984333182L;

    public List<Category> getAllCategories() {
        // TODO
    }

    public List<Post> getAllPostsOfCategory(Integer categoryId) {
        // TODO
    }

    @Transactional(value = TxType.REQUIRES_NEW, rollbackOn = RuntimeException.class)
    public void createCategory(final String name, final String description)
            throws DaoJpaException {
        // TODO
    }
}

我只能想到两个 CDI 作用域：

@SessionScope：对我来说，这似乎是最合适的范围，因为单个实例专用于活动会话。
@Dependent：也是合理的，因为这样的实例将适合注入它的对象的生命周期。

我认为所有其他 CDI 范围都不合适：

@ApplicationScoped：由于应用程序范围的存储库一次只会创建一次，因此像：entityManager.clear() 这样的调用将导致所有当前会话的所有实例也将被分离。此外，这个单一的存储库必须处理所有传入的请求。可能此范围适用于只读存储库？
@RequestScope：我认为没有必要为每个传入的请求创建一个新的存储库实例。
@ConversionScoped：转换通常在 GUI 层强制执行。如果我希望存储库在转换结束后终止，我可以将其定义为 @Dependent。

那么，对于这个问题，是否有任何已知的最佳实践？

【问题讨论】：

标签： java jakarta-ee jpa scope cdi

【解决方案1】：

描述所有选项

会话范围实际上没有意义，因为您的存储库应该是无状态的，因此会话对它没有意义（尽管它会解决并发问题
依赖范围可能是一个不错的选择，但它可能会导致内存泄漏（您永远无法确定将从内存中删除哪些依赖对象）
对话范围也没有任何意义，与会话范围相同

所以我会选择任何一个

请求范围 - 我会说这是最好的选择，它本质上是无状态的，因此您可以避免任何并发问题。也不必担心性能，在新的 JVM 中创建新对象真的非常快
应用范围也可能是一个不错的选择，但是您需要担心并发问题（多个客户端同时调用相同的方法）。

所以如果我是你，我会选择请求范围存储库，这是最简单的选择，这样你就可以避免所有问题。

【讨论】：

谢谢，@Version属性使用@ApplicationScoped解决并发问题了吗？
老实说，我不确定，因为 javadoc 只谈论在合并实体时保持完整性，在我看来这还不够。
我认为乐观和悲观锁的使用应该可以解决并发问题。

【解决方案2】：

你应该使用@ApplicationScoped。

每个请求都应该使用 EntityManager，而不是重复使用。

在请求请求时，您创建 entityManager，当它完成提交或回滚时。

@Dependent 将具有与其“主机”相同的范围，如果您将其注入 @RequestScoped 并且 bean 将具有相同的范围。

@SessionScoped 应仅用于小数据（如用户登录和权限）。

【讨论】：