11.2. 数据库事务声明

如果Hibernat持久层运行在一个非托管环境中，数据库连接通常由Hibernate的简单（即非DataSource)连接池机制 来处理。session/transaction处理方式如下所示：

//Non-managed environment idiom
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();
}

你不需要显式flush() Session - 对commit()的调用会自动触发session的同步(取决于session的第 10.10 节 “Session刷出(flush)”)。调用 close() 标志session的结束。close()方法重要的暗示是，session释放了JDBC连接。这段Java代码在非托管环境下和JTA环境下都可以运行。

更加灵活的方案是Hibernate内置的"current session"上下文管理，前文已经讲过：

// Non-managed environment idiom with getCurrentSession()
try {
    factory.getCurrentSession().beginTransaction();

    // do some work
    ...

    factory.getCurrentSession().getTransaction().commit();
}
catch (RuntimeException e) {
    factory.getCurrentSession().getTransaction().rollback();
    throw e; // or display error message
}

你很可能从未在一个通常的应用程序的业务代码中见过这样的代码片断：致命的（系统）异常应该总是 在应用程序“顶层”被捕获。换句话说，执行Hibernate调用的代码（在持久层）和处理 RuntimeException异常的代码（通常只能清理和退出应用程序）应该在不同 的应用程序逻辑层。Hibernate的当前上下文管理可以极大地简化这一设计，你所有的一切就是SessionFactory。 异常处理将在本章稍后进行讨论。

请注意，你应该选择 org.hibernate.transaction.JDBCTransactionFactory (这是默认选项)，对第二个例子来说，hibernate.current_session_context_class应该是"thread"

如果你的持久层运行在一个应用服务器中（例如，在EJB session beans的后面），Hibernate获取 的每个数据源连接将自动成为全局JTA事务的一部分。 你可以安装一个独立的JTA实现，使用它而不使用EJB。Hibernate提供了两种策略进行JTA集成。

如果你使用bean管理事务（BMT），可以通过使用Hibernate的 Transaction API来告诉 应用服务器启动和结束BMT事务。因此，事务管理代码和在非托管环境下是一样的。

// BMT idiom
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();
}

如果你希望使用与事务绑定的Session，也就是使用getCurrentSession()来简化上下文管理，你将不得不直接使用JTA UserTransactionAPI。

// BMT idiom with getCurrentSession()
try {
    UserTransaction tx = (UserTransaction)new InitialContext()
                            .lookup("java:comp/UserTransaction");

    tx.begin();

    // Do some work on Session bound to transaction
    factory.getCurrentSession().load(...);
    factory.getCurrentSession().persist(...);

    tx.commit();
}
catch (RuntimeException e) {
    tx.rollback();
    throw e; // or display error message
}

在CMT方式下，事务声明是在session bean的部署描述符中，而不需要编程。 因此，代码被简化为:

// CMT idiom
Session sess = factory.getCurrentSession();

// do some work
...

在CMT/EJB中甚至会自动rollback，因为假若有未捕获的RuntimeException从session bean方法中抛出，这就会通知容器把全局事务回滚。这就意味着，在BMT或者CMT中，你根本就不需要使用Hibernate Transaction API ，你自动得到了绑定到事务的“当前”Session。

注意，当你配置Hibernate的transaction factory的时候，在直接使用JTA的时候（BMT），你应该选择org.hibernate.transaction.JTATransactionFactory,在CMT session bean中选择org.hibernate.transaction.CMTTransactionFactory。记得也要设置hibernate.transaction.manager_lookup_class。还有，确认你的hibernate.current_session_context_class未设置（为了向下兼容），或者设置为"jta"。

getCurrentSession()在JTA环境中有一个弊端。对after_statement连接释放方式有一个警告，这是被默认使用的。因为JTA规范的一个很愚蠢的限制，Hibernate不可能自动清理任何未关闭的ScrollableResults 或者Iterator，它们是由scroll()或iterate()产生的。你must通过在finally块中，显式调用ScrollableResults.close()或者Hibernate.close(Iterator)方法来释放底层数据库游标。(当然，大部分程序完全可以很容易的避免在JTA或CMT代码中出现scroll()或iterate()。)

如果 Session 抛出异常 (包括任何SQLException), 你应该立即回滚数据库事务，调用 Session.close() ，丢弃该 Session实例。Session的某些方法可能会导致session 处于不一致的状态。所有由Hibernate抛出的异常都视为不可以恢复的。确保在 finally 代码块中调用close()方法，以关闭掉 Session。

HibernateException是一个非检查期异常（这不同于Hibernate老的版本）， 它封装了Hibernate持久层可能出现的大多数错误。我们的观点是，不应该强迫应用程序开发人员 在底层捕获无法恢复的异常。在大多数软件系统中，非检查期异常和致命异常都是在相应方法调用 的堆栈的顶层被处理的（也就是说，在软件上面的逻辑层），并且提供一个错误信息给应用软件的用户 （或者采取其他某些相应的操作）。请注意，Hibernate也有可能抛出其他并不属于 HibernateException的非检查期异常。这些异常同样也是无法恢复的，应该 采取某些相应的操作去处理。

在和数据库进行交互时，Hibernate把捕获的SQLException封装为Hibernate的 JDBCException。事实上，Hibernate尝试把异常转换为更有实际含义 的JDBCException异常的子类。底层的SQLException可以 通过JDBCException.getCause()来得到。Hibernate通过使用关联到 SessionFactory上的SQLExceptionConverter来 把SQLException转换为一个对应的JDBCException 异常的子类。默认情况下，SQLExceptionConverter可以通过配置dialect 选项指定；此外，也可以使用用户自定义的实现类（参考javadocs SQLExceptionConverterFactory类来了解详情）。标准的 JDBCException子类型是：

EJB这样的托管环境有一项极为重要的特性，而它从未在非托管环境中提供过，那就是事务超时。在出现错误的事务行为的时候，超时可以确保不会无限挂起资源、对用户没有交代。在托管(JTA)环境之外，Hibernate无法完全提供这一功能。但是，Hiberante至少可以控制数据访问，确保数据库级别的死锁，和返回巨大结果集的查询被限定在一个规定的时间内。在托管环境中，Hibernate会把事务超时转交给JTA。这一功能通过Hibernate Transaction对象进行抽象。

Session sess = factory.openSession();
try {
    //set transaction timeout to 3 seconds
    sess.getTransaction().setTimeout(3);
    sess.getTransaction().begin();

    // do some work
    ...

    sess.getTransaction().commit()
}
catch (RuntimeException e) {
    sess.getTransaction().rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

注意setTimeout()不应该在CMT bean中调用，此时事务超时值应该是被声明式定义的。