Spring Boot+Hibernate环境下如何在事务外正确初始化懒加载集合

失效原因 #

你之前的方案报错，核心是findById返回的User实体在父查询事务结束后就已脱离持久化上下文（脱管状态），即使子解析器开启了新事务，这个脱管实体也未和新事务的Session绑定，直接调用Hibernate.initialize自然会抛出找不到Session的异常。

可选方案（均满足你提出的限制条件） #

方案1：子解析器内合并脱管实体后初始化 #

在子解析器的事务中，先将脱管的User实体合并到当前持久化上下文，再初始化关联集合，全程由Hibernate管理关联逻辑：

@DgsComponent
public class UserDataFetcher {
    @Autowired
    private UserService userService;
    @Autowired
    private EntityManager entityManager;

    @DgsQuery
    public User getUserById(@InputArgument UUID id) {
        return userService.findById(id);
    }

    @DgsData(parentType = "User", field = "articles")
    @Transactional(readOnly = true)
    public List<Article> getArticle(DgsDataFetchingEnvironment dfe) {
        User detachedUser = dfe.getSource();
        // 将脱管实体合并到当前事务的Session，实体无修改则不会触发额外更新操作
        User managedUser = entityManager.merge(detachedUser);
        Hibernate.initialize(managedUser.getArticles());
        return managedUser.getArticles();
    }
}

说明：该方案改动最小，完全复用Hibernate的关联配置，不需要手动编写关联查询逻辑。

方案2：父查询动态按需抓取关联（性能更优） #

利用DGS可获取请求选中字段的特性，在父查询的同一个事务内，根据请求字段动态决定是否抓取关联集合，仅需一次数据库查询，无额外开销：
第一步：修改父解析器，传入当前请求的选中字段：

@DgsQuery
public User getUserById(@InputArgument UUID id, DgsDataFetchingEnvironment dfe) {
    Set<String> selectedFields = dfe.getSelectionSet().getFields();
    return userService.findByIdWithDynamicFetch(id, selectedFields);
}

第二步：在Service层实现动态抓取逻辑：

@Service
public class UserServiceImpl implements UserService {
    @Autowired
    private EntityManager entityManager;

    @Override
    @Transactional(readOnly = true)
    public User findByIdWithDynamicFetch(UUID id, Set<String> selectedFields) {
        CriteriaBuilder cb = entityManager.getCriteriaBuilder();
        CriteriaQuery<User> cq = cb.createQuery(User.class);
        Root<User> root = cq.from(User.class);
        // 仅当请求包含articles字段时才抓取关联集合
        if (selectedFields.contains("articles")) {
            root.fetch("articles", JoinType.LEFT);
        }
        cq.select(root).where(cb.equal(root.get("id"), id));
        return entityManager.createQuery(cq).getSingleResult();
    }
}

说明：该方案性能最优，避免了子解析器额外的数据库查询，也不需要单独维护关联字段的子解析器，后续新增关联字段只需加对应的判断逻辑即可。

关于你排除的直接查关联表方案的补充说明 #

你的顾虑是合理的：直接通过用户ID查询文章列表相当于手动实现了Hibernate的关联解析逻辑，后续如果实体关联新增了过滤规则（比如软删除、租户隔离、权限校验），需要同时维护实体注解和手动查询的两份逻辑，确实没有充分利用ORM的能力，上述两个方案均不存在该问题。

内容的提问来源于stack exchange，提问作者Adil Waqar