1. Session和事务范围(transaction scope)
SessionFactory对象的创建代价很昂贵，它是线程安全的对象，它为所有的应用程序线程所共享。它只创建一次，通常是在应用程序启动的时候，由一个Configuraion的实例来创建。
Session对象的创建代价比较小，是非线程安全的，对于单个请求，单个会话、单个的 工作单元而言，它只被使用一次，然后就丢弃。只有在需要的时候，一个Session对象 才会获取一个JDBC的Connection（或一个Datasource） 对象，因此假若不使用的时候它不消费任何资源。
此外我们还要考虑数据库事务。数据库事务应该尽可能的短，降低数据库中的锁争用。 数据库长事务会阻止你的应用程序扩展到高的并发负载。因此，假若在用户思考期间让数据库事务开着，直到整个工作单元完成才关闭这个事务，这绝不是一个好的设计。
一个操作单元(Unit of work)的范围是多大？单个的Hibernate Session能跨越多个 数据库事务吗？还是一个Session的作用范围对应一个数据库事务的范围？应该何时打开 Session，何时关闭Session？，你又如何划分数据库事务的边界呢？
1.1 操作单元(Unit of work)
首先，别用session-per-operation这种反模式了，也就是说，在单个线程中， 不要因为一次简单的数据库调用，就打开和关闭一次Session！数据库事务也是如此。 应用程序中的数据库调用是按照计划好的次序，分组为原子的操作单元。（注意，这也意味着，应用程 序中，在单个的SQL语句发送之后，自动事务提交(auto-commit)模式失效了。这种模式专门为SQL控制台操作设计的。 Hibernate禁止立即自动事务提交模式，或者期望应用服务器禁止立即自动事务提交模式。）数据库事务绝不是可有可无的，任何与数据库之间的通讯都必须在某个事务中进行，不管你是在读还是在写数据。对读数据而言，应该避免auto-commit行为，因为很多小的事务比一个清晰定义的工作单元性能差。后者也更容易维护和扩展。
在多用户的client/server应用程序中，最常用的模式是 每个请求一个会话(session-per-request)。 在这种模式下，来自客户端的请求被发送到服务器端（即Hibernate持久化层运行的地方），一 个新的Hibernate Session被打开，并且执行这个操作单元中所有的数据库操作。 一旦操作完成（同时对客户端的响应也准备就绪），session被同步，然后关闭。你也可以使用单 个数据库事务来处理客户端请求，在你打开Session之后启动事务，在你关闭 Session之前提交事务。会话和请求之间的关系是一对一的关系，这种模式对 于大多数应用程序来说是很棒的。
实现才是真正的挑战。Hibernate内置了对"当前session(current session)" 的管理，用于简化此模式。你要做的一切就是在服务器端要处理请求的时候，开启事务，在响应发送给客户之前结束事务。你可以用任何方式来完成这一操作，通常的方案有ServletFilter，在service方法中进行pointcut的AOP拦截器，或者proxy/interception容器。EJB容器是实现横切诸如EJB session bean上的事务分界，用CMT对事务进行声明等方面的标准手段。假若你决定使用编程式的事务分界，请参考本章后面讲到的Hibernate Transaction API，这对易用性和代码可移植性都有好处。
在任何时间，任何地方，你的应用代码可以通过简单的调用sessionFactory.getCurrentSession()来访问"当前session"，用于处理请求。你总是会得到当前数据库事务范围内的Session。在使用本地资源或JTA环境时，必须配置它，请参见第 2.5 节 “上下文相关的（Contextual）Session”。
有时，将Session和数据库事务的边界延伸到"展示层被渲染后"会带来便利。有些serlvet应用程序在对请求进行处理后，有个单独的渲染期，这种延伸对这种程序特别有用。假若你实现你自己的拦截器，把事务边界延伸到展示层渲染结束后非常容易。然而，假若你依赖有容器管理事务的EJB，这就不太容易了，因为事务会在EJB方法返回后结束，而那是在任何展示层渲染开始之前。请访问Hibernate网站和论坛，你可以找到Open Session in View这一模式的提示和示例。
1.1 长对话
session-per-request模式不仅仅是一个可以用来设计操作单元的有用概念。很多业务处理都需 要一系列完整的与用户之间的交互，而这些用户是指对数据库有交叉访问的用户。在基于web的应用和企业 应用中，跨用户交互的数据库事务是无法接受的。考虑下面的例子：
从用户的角度来看，我们把这个操作单元称为长时间运行的对话（conversation）,或者(or 应用事务,application transaction)。 在你的应用程序中，可以有很多种方法来实现它。
头一个幼稚的做法是，在用户思考的过程中，保持Session和数据库事务是打开的， 保持数据库锁定，以阻止并发修改，从而保证数据库事务隔离级别和原子操作。这种方式当然是一个反模式， 因为锁争用会导致应用程序无法扩展并发用户的数目。
很明显，我们必须使用多个数据库事务来实现这个对话。在这个例子中，维护业务处理的 事务隔离变成了应用程序层的部分责任。一个对话通常跨越多个数据库事务。如果仅仅只有一 个数据库事务（最后的那个事务）保存更新过的数据，而所有其他事务只是单纯的读取数据（例如在一 个跨越多个请求/响应周期的向导风格的对话框中），那么应用程序事务将保证其原子性。这种方式比听 起来还要容易实现，特别是当你使用了Hibernate的下述特性的时候：
-
自动版本化 - Hibernate能够自动进行乐观并发控制 ，如果在用户思考 的过程中发生并发修改，Hibernate能够自动检测到。一般我们只在对话结束时才检查。
-
脱管对象（Detached Objects）- 如果你决定采用前面已经讨论过的 session-per-request模式，所有载入的实例在用户思考的过程 中都处于与Session脱离的状态。Hibernate允许你把与Session脱离的对象重新关联到Session 上，并且对修改进行持久化，这种模式被称为 session-per-request-with-detached-objects。自动版本化被用来隔离并发修改。
-
Extended (or Long) Session - Hibernate 的Session 可以在数据库事务提交之后和底层的JDBC连接断开，当一个新的客户端请求到来的时候，它又重新连接上底层的 JDBC连接。这种模式被称之为session-per-conversation，这种情况可 能会造成不必要的Session和JDBC连接的重新关联。自动版本化被用来隔离并发修改, Session通常不允许自动flush,而是明确flush。
session-per-request-with-detached-objects 和 session-per-conversation 各有优缺点，我们在本章后面乐观并发 控制那部分再进行讨论。