如何中断休眠会话?

在什么情况下,引发HibernateException后,Hibernate会话确实变得不可用?

有趣的问题。我很肯定我已经看到过这样的情况,在这种例外之后,会话仍然“工作”。问题可能是这并不能保证。我需要再多挖一点。

更新: 报价 this message 来自Hibernate论坛中的Hibernate开发人员:

当发生任何异常时,应丢弃休眠会话。相对于数据库,它可以处于不一致的状态。只读会话不是这样,因为它不使用任何会话级缓存。或者,您可以在发生异常时清除会话级缓存(但我个人不喜欢这种方法,因为它不是一个干净的解决方案,而且可能导致将来的问题和问题)。

所以问题不在于 Session 是否“技术上可用”,问题在于它的行为可能与预期不符。你显然不想这样。

如何在测试中重现?

您可以故意违反导致抛出子类的条件,例如违反完整性约束以获取 ConstraintViolationException . 像这样的情况怎么样:

Session session = HibernateUtil.getCurrentSession();

try {
    session.beginTransaction();    
    // execute some code that violates a unique constraint
    ...
    session.getTransaction().commit();  
} catch (HibernateException e) {
    session.getTransaction().rollback();
}

// keep using the session
try {
    session.beginTransaction();    
    ...
    session.getTransaction().commit();  
} catch (HibernateException e) {
    session.getTransaction().rollback();
}
// do we reach this point?

但我不确定这会证明什么。我的意思是,如果会议仍在进行中,我们只能对这个特定的案件作出结论。

更新: 忘了我的建议,它不会证明什么。事实上,我认为在一个 HibernateException . 所以,我不想证明什么,我想正确的做法是遵循建议(或建议的替代方案),但我只要求一个新的 会议 和 close 它适用于每个事务,是否引发异常)。

这种测试的恰当术语是什么?

集成测试?稳健性测试?

有趣的一个。最好的方法是去看看Hibernate的来源。据我所知, Session 除了以下内容外,不会携带太多状态:

• 一级缓存(请参见 StatefulPersistenceContext )--它可能在事务失败后实际被破坏;
• 动作队列(请参见 ActionQueue )--手动冲洗似乎没问题;
• 事件监听器——它们的实例知道会话(请参见 EventSource )而且,正如您可能注意到的,JDBC异常总是由 冲洗 ( DefaultFlushEventListener ,更准确地说),但快速浏览一下 AbstractFlushingEventListener 显示它们实际使用会话的 JDBCContext 和 ActionQueue .

最后一点,事务本身的回滚不会以任何方式干扰会话状态,请参见 JDBCTransaction .

就我而言, 会话 实际上,除了一级缓存可能有点不准确之外,还可以在错误的事务中存活下来;要解决这个问题,您可能更愿意调用 session.refresh 或 session.load 明确地重新同步状态。

编辑:测试JDBC异常的最快方法可能是 session.createSQLQuery("something offensive to SQL parser").executeUpdate() --你会得到一个完美的 SQLGrammarException --和一个中断的事务=)

我的观点是

1. 几乎不可能知道Hibernate是否可以工作,它遇到了一个意外的情况,现在正以未定义的状态运行-基本上,您将通过在会话上执行更多的操作来调用UB。

2. 想法-注册一个拦截器并在其中抛出一个HibernateException-希望Hibernate不会捕获它:d

3. 故障注入?

为测试创建会话的子类。实现它以在某些特定场景中引发异常。使用特定于测试的Hibernate配置,该配置将Hibernate设置为使用测试会话。