如果不在Hibernate中回滚事务，会发生什么？

 

我所读到的关于Hibernate的一切都表明，当发生错误时，您必须回滚事务并关闭会话，并且通常会给出以下代码（取自Hibernate的文档）的一些变体，例如： 

Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();
    // do some work
    ...
    tx.commit();
} catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // or display error message
} finally {
    sess.close();
}

出于几个原因，这种模式对我来说似乎很奇怪。 首先，对于一个通常旨在简化事情的框架来说，看起来似乎过于复杂。 更重要的是，如果try块中的代码抛出RuntimeException之外的其他内容，会发生什么情况？ 看起来好像Hibernate必须能够在这种情况下正常关闭会话，大概是通过回滚，但如果这是真的，为什么麻烦调用rollback呢？

Hibernate可能使许多事情变得更简单，但事务管理并不是很简单，因此对于每一个事务，你都必须非常仔细地考虑你想要的东西。 Hibernate无法帮助你。

如果try块中的代码抛出除RuntimeException之外的任何其他内容，那么您的事务显然不会提交。 但是你也没有明确地回滚。 您的finally块中的sess.Close调用也不会回滚事务。 发生什么取决于这是否是嵌套事务：

  • 如果不是，则最终交易超时并回滚。
  • 如果是这样，父事务将看到子事务在提交时没有提交。 这将导致整个事务的回滚。

    • 更重要的是，如果try块中的代码抛出RuntimeException之外的其他内容，会发生什么情况？

    如果RuntimeException之外的try块中的代码块中有任何其他异常，那么这必须是一个检查异常，它将被编译器本身捕获，并且最终将把处理部分合并到你的代码。

    在这个问题提供的例子中，我们只捕获RuntimeException，这是我认为是正确的编码方式。 通过这样做，我们可以立即回滚事务，而无需等待事务超时和最终回滚。 当我们继续抛出RuntimeException时，我们也没有打破异常流程。 这是更清晰和更明确的处理事务的方式，而不是让事务超时触发事务的回滚。

    当然，我们不应该以捕获RuntimeException的方式捕获'Exception'，原因很明显。

    链接地址: http://www.djcxy.com/p/47585.html

    上一篇: What happens if you don't roll back a transaction in Hibernate?

    下一篇: Android RelativeLayout height not following GridView height