Hibernate的事务和并发控制很容易掌握。Hibernate直接使用JDBC连接和JTA资源，不添加任何附加锁定 行为。我们强烈推荐你花点时间了解JDBC编程，ANSI SQL查询语言和你使用 的数据库系统的事务隔离规范。Hibernate只添加自动版本管理，而不会锁 定内存中的对象，也不会改变数据库事务的隔离级别。基本上，使用 Hibernate就好像直接使用JDBC(或者JTA/CMT)来访问你的数据库资源。
除了自动版本管理，针对行级悲观锁定，Hibernate也提供了辅助的API，它使用了 SELECT FOR UPDATE的SQL语法。本章后面会讨论这个API。
我们从Configuration层、SessionFactory层, 和 Session层开始讨论Hibernate的并行控制、数据库事务和应用 程序的长事务。
12.1.Session和事务范围(transaction scopes)
一个SessionFactory对象的创建代价很昂贵，它是线程安全的对象，它被设计成可以 为所有的应用程序线程所共享。它只创建一次，通常是在应用程序启动的时候，由一个 Configuraion的实例来创建。
一个Session的对象是轻型的，非线程安全的，对于单个业务进程，单个的 工作单元而言，它只被使用一次，然后就丢弃。只有在需要的时候，Session 才会获取一个JDBC的Connection（或一个Datasource） 对象。所以你可以放心的打开和关闭Session，甚至当你并不确定一个特定的请 求是否需要数据访问时，你也可以这样做。(一旦你实现下面提到的使用了请求拦截的模式，这就 变得很重要了。
此外我们还要考虑数据库事务。数据库事务应该尽可能的短，降低数据库锁定造成的资源争用。 数据库长事务会导致你的应用程序无法扩展到高的并发负载。
一个操作单元(Unit of work)的范围是多大？单个的Hibernate Session能跨越多个 数据库事务吗？还是一个Session的作用范围对应一个数据库事务的范围？应该何时打开 Session，何时关闭Session？，你又如何划分数据库事务的边界呢？
12.1.1.操作单元(Unit of work)
首先，别再用session-per-operation这种反模式了，也就是说，在单个线程中， 不要因为一次简单的数据库调用，就打开和关闭一次Session！数据库事务也是如此。 应用程序中的数据库调用是按照计划好的次序，分组为原子的操作单元。（注意，这也意味着，应用程 序中，在单个的SQL语句发送之后，自动事务提交(auto-commit)模式失效了。这种模式专门为SQL控制台操作设计的。 Hibernate禁止立即自动事务提交模式，或者期望应用服务器禁止立即自动事务提交模式。）
在多用户的client/server应用程序中，最常用的模式是 每个请求一个会话(session-per-request)。 在这种模式下，来自客户端的请求被发送到服务器端（即Hibernate持久化层运行的地方），一 个新的Hibernate Session被打开，并且执行这个操作单元中所有的数据库操作。 一旦操作完成（同时发送到客户端的响应也准备就绪），session被同步，然后关闭。你也可以使用单 个数据库事务来处理客户端请求，在你打开Session之后启动事务，在你关闭 Session之前提交事务。会话和请求之间的关系是一对一的关系，这种模式对 于大多数应用程序来说是很棒的。
真正的挑战在于如何去实现这种模式：不仅Session和事务必须被正确的开始和结束， 而且他们也必须能被数据访问操作访问。用拦截器来实现操作单元的划分，该拦截器在客户端请求达到服 务器端的时候开始，在服务器端发送响应（即，ServletFilter）之前结束。我们推荐 使用一个ThreadLocal 变量，把 Session绑定到处理客户端请求的线 程上去。这种方式可以让运行在该线程上的所有程序代码轻松的访问Session（就像访问一 个静态变量那样）。你也可以在一个ThreadLocal 变量中保持事务上下文环境，不过这依赖 于你所选择的数据库事务划分机制。这种实现模式被称之为 ThreadLocal Session和 Open Session in View。你可以很容易的扩展本文前面章节展示的 HibernateUtil 辅助类来实现这种模式。当然，你必须找到一种实现拦截器的方法，并 且可以把拦截器集成到你的应用环境中。请参考Hibernate网站上面的提示和例子。