Hibernate的事务和并发

转载http://developer.51cto.com/art/200611/34161.htm

文章很长，粘贴过来有些费劲，而且不能收藏。。。

点击链接看吧，可以看完一般不分粘一部分，也算做个记录

Hibernate的事务和并发(1)

Hibernate直接使用JDBC连接和JTA资源，不添加任何附加锁定行为。我们强烈推荐你花点时间了解JDBC编程，ANSI SQL查询语言和你使用的数据库系统的事务隔离规范。我们从Configuration层、SessionFactory层, 和Session层开始讨论Hibernate的并行控制、数据库事务和应用程序的长事务。

Hibernate的事务和并发控制很容易掌握。Hibernate直接使用JDBC连接和JTA资源，不添加任何附加锁定行为。我们强烈推荐你花点时间了解JDBC编程，ANSI SQL查询语言和你使用的数据库系统的事务隔离规范。Hibernate只添加自动版本管理，而不会锁定内存中的对象，也不会改变数据库事务的隔离级别。基本上，使用Hibernate就好像直接使用JDBC(或者JTA/CMT)来访问你的数据库资源。

除了自动版本管理，针对行级悲观锁定，Hibernate也提供了辅助的API，它使用了SELECT FOR UPDATE的SQL语法。本章后面会讨论这个API。

我们从Configuration层、SessionFactory层, 和Session层开始讨论Hibernate的并行控制、数据库事务和应用程序的长事务。

1.1.Session和事务范围(transaction scopes)

一个SessionFactory对象的创建代价很昂贵，它是线程安全的对象，它被设计成可以为所有的应用程序线程所共享。它只创建一次，通常是在应用程序启动的时候，由一个Configuraion的实例来创建。

一个Session的对象是轻型的，非线程安全的，对于单个业务进程，单个的工作单元而言，它只被使用一次，然后就丢弃。只有在需要的时候，Session才会获取一个JDBC的Connection（或一个Datasource）对象。所以你可以放心的打开和关闭Session，甚至当你并不确定一个特定的请求是否需要数据访问时，你也可以这样做。(一旦你实现下面提到的使用了请求拦截的模式，这就变得很重要了。

此外我们还要考虑数据库事务。数据库事务应该尽可能的短，降低数据库锁定造成的资源争用。数据库长事务会导致你的应用程序无法扩展到高的并发负载。

一个操作单元(Unit of work)的范围是多大？单个的Hibernate Session能跨越多个数据库事务吗？还是一个Session的作用范围对应一个数据库事务的范围？应该何时打开Session，何时关闭Session？，你又如何划分数据库事务的边界呢？

1.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和OpenSession in View。你可以很容易的扩展本文前面章节展示的HibernateUtil辅助类来实现这种模式。当然，你必须找到一种实现拦截器的方法，并且可以把拦截器集成到你的应用环境中。请参考Hibernate网站上面的提示和例子。

1.1.2.应用程序事务(Application transactions)

session-per-request模式不仅仅是一个可以用来设计操作单元的有用概念。很多业务处理流程都需要一系列完整的和用户之间的交互，即用户对数据库的交叉访问。在基于web的应用和企业应用中，跨用户交互的数据库事务是无法接受的。考虑下面的例子：

在界面的第一屏，打开对话框，用户所看到的数据是被一个特定的Session和数据库事务载入(load)的。用户可以随意修改对话框中的数据对象。

5分钟后，用户点击“保存”，期望所做出的修改被持久化；同时他也期望自己是唯一修改这个信息的人，不会出现修改冲突。

从用户的角度来看，我们把这个操作单元称为应用程序长事务（application transaction）。在你的应用程序中，可以有很多种方法来实现它。

头一个幼稚的做法是，在用户思考的过程中，保持Session和数据库事务是打开的，保持数据库锁定，以阻止并发修改，从而保证数据库事务隔离级别和原子操作。这种方式当然是一个反模式，因为数据库锁定的维持会导致应用程序无法扩展并发用户的数目。

很明显，我们必须使用多个数据库事务来实现一个应用程序事务。在这个例子中，维护业务处理流程的事务隔离变成了应用程序层的部分责任。单个应用程序事务通常跨越多个数据库事务。如果仅仅只有一个数据库事务（最后的那个事务）保存更新过的数据，而所有其他事务只是单纯的读取数据（例如在一个跨越多个请求/响应周期的向导风格的对话框中），那么应用程序事务将保证其原子性。这种方式比听起来还要容易实现，特别是当你使用了Hibernate的下述特性的时候：

自动版本化-Hibernate能够自动进行乐观并发控制，如果在用户思考的过程中发生并发修改冲突，Hibernate能够自动检测到。

脱管对象（Detached Objects）-如果你决定采用前面已经讨论过的session-per-request模式，所有载入的实例在用户思考的过程中都处于与Session脱离的状态。Hibernate允许你把与Session脱离的对象重新

关联到Session上，并且对修改进行持久化，这种模式被称为session-per-request-with-detached-objects。自动版本化被用来隔离并发修改。

长生命周期的Session（Long Session）-Hibernate的Session可以在数据库事务提交之后和底层的JDBC连接断开，当一个新的客户端请求到来的时候，它又重新连接上底层的JDBC连接。这种模式被称之为session-per-application-transaction，这种情况可能会造成不必要的Session和JDBC连接的重新关联。

自动版本化被用来隔离并发修改。

session-per-request-with-detached-objects和session-per-application-transaction各有优缺点，我们在本章后面乐观并发控制那部分再进行讨论。