 |
|
|
|
12.3.乐观并发控制(Optimistic concurrency control)
唯一能够同时保持高并发和高可伸缩性的方法就是使用带版本化的乐观并发控制。版本检查使用版本号、 或者时间戳来检测更新冲突（并且防止更新丢失）。Hibernate为使用乐观并发控制的代码提供了三种可 能的方法，应用程序在编写这些代码时，可以采用它们。我们已经在前面应用程序长事务那部分展示了 乐观并发控制的应用场景，此外，在单个数据库事务范围内，版本检查也提供了防止更新丢失的好处。
12.3.1.应用程序级别的版本检查(Application version checking)
未能充分利用Hibernate功能的实现代码中，每次和数据库交互都需要一个新的 Session，而且开发人员必须在显示数据之前从数据库中重 新载入所有的持久化对象实例。这种方式迫使应用程序自己实现版本检查来确保 应用程序事务的隔离，从数据访问的角度来说是最低效的。这种使用方式和 entity EJB最相似。
// foo is an instance loaded by a previous Session
session = factory.openSession();
Transaction t = session.beginTransaction();
int oldVersion = foo.getVersion();
session.load( foo, foo.getKey() ); // load the current state
if ( oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
foo.setProperty("bar");
t.commit();
session.close();
version 属性使用 来映射，如果对象 是脏数据，在同步的时候，Hibernate会自动增加版本号。
当然，如果你的应用是在一个低数据并发环境下，并不需要版本检查的话，你照样可以使用 这种方式，只不过跳过版本检查就是了。在这种情况下，最晚提交生效 （last commit wins）就是你的应用程序长事务的默认处理策略。 请记住这种策略可能会让应用软件的用户感到困惑，因为他们有可能会碰上更新丢失掉却没 有出错信息，或者需要合并更改冲突的情况。
很明显，手工进行版本检查只适合于某些软件规模非常小的应用场景，对于大多数软件应用场景 来说并不现实。通常情况下，不仅是单个对象实例需要进行版本检查，整个被修改过的关 联对象图也都需要进行版本检查。作为标准设计范例，Hibernate使用长生命周期 Session的方式，或者脱管对象实例的方式来提供自动版本检查。
12.3.2.长生命周期session和自动版本化
单个 Session实例和它所关联的所有持久化对象实例都被用于整个 应用程序事务。Hibernate在同步的时候进行对象实例的版本检查，如果检测到并发修 改则抛出异常。由开发人员来决定是否需要捕获和处理这个异常（通常的抉择是给用户 提供一个合并更改，或者在无脏数据情况下重新进行业务操作的机会）。
在等待用户交互的时候， Session 断开底层的JDBC连接。这种方式 以数据库访问的角度来说是最高效的方式。应用程序不需要关心版本检查或脱管对象实例 的重新关联，在每个数据库事务中，应用程序也不需要载入读取对象实例。
代码内容
// foo is an instance loaded earlier by the Session
session.reconnect(); // Obtain a new JDBC connection
Transaction t = session.beginTransaction();
foo.setProperty("bar");
t.commit(); // End database transaction, flushing the change and checking the version
session.disconnect(); // Return JDBC connection
foo 对象始终和载入它的Session相关联。 Session.reconnect()获取一个新的数据库连接（或者 你可以提供一个），并且继续当前的session。Session.disconnect() 方法把session与JDBC连接断开，把数据库连接返回到连接池（除非是你自己提供的数据 库连接）。在Session重新连接上数据库连接之后，你可以对任何可能被其他事务更新过 的对象调用Session.lock()，设置LockMode.READ 锁定模式，这样你就可以对那些你不准备更新的数据进行强制版本检查。此外，你并不需要 锁定那些你准备更新的数据。
假若对disconnect()和reconnect()的显式调用发生得太频繁了，你可以使用hibernate.connection.release_mode来代替。
如果在用户思考的过程中，Session因为太大了而不能保存，那么这种模式是有 问题的。举例来说，一个HttpSession应该尽可能的小。由于 Session是一级缓存，并且保持了所有被载入过的对象，因此 我们只应该在那些少量的request/response情况下使用这种策略。而且在这种情况下， Session 里面很快就会有脏数据出现，因此请牢牢记住这一建议。
此外，也请注意，你应该让与数据库连接断开的Session对持久层保持 关闭状态。换句话说，使用有状态的EJB session bean来持有Session， 而不要把它传递到web层（甚至把它序列化到一个单独的层），保存在HttpSession中。
12.3.3.脱管对象(deatched object)和自动版本化
这种方式下，与持久化存储的每次交互都发生在一个新的Session中。 然而，同一持久化对象实例可以在多次与数据库的交互中重用。应用程序操纵脱管对象实例 的状态，这个脱管对象实例最初是在另一个Session 中载入的，然后 调用 Session.update()，Session.saveOrUpdate(), 或者 Session.merge() 来重新关联该对象实例。
代码内容
// foo is an instance loaded by a previous Session
foo.setProperty("bar");
session = factory.openSession();
Transaction t = session.beginTransaction();
session.saveOrUpdate(foo); // Use merge() if "foo" might have been loaded already
t.commit();
session.close();
Hibernate会再一次在同步的时候检查对象实例的版本，如果发生更新冲突，就抛出异常。
如果你确信对象没有被修改过，你也可以调用lock() 来设置 LockMode.READ（绕过所有的缓存，执行版本检查），从而取 代 update()操作。
12.3.4.定制自动版本化行为
对于特定的属性和集合，通过为它们设置映射属性optimistic-lock的值 为false，来禁止Hibernate的版本自动增加。这样的话，如果该属性 脏数据，Hibernate将不再增加版本号。
遗留系统的数据库Schema通常是静态的，不可修改的。或者，其他应用程序也可能访问同一数据 库，根本无法得知如何处理版本号，甚至时间戳。在以上的所有场景中，实现版本化不能依靠 数据库表的某个特定列。在的映射中设置 optimistic-lock="all"可以在没有版本或者时间戳属性映射的情况下实现 版本检查，此时Hibernate将比较一行记录的每个字段的状态。请注意，只有当Hibernate能够比 较新旧状态的情况下，这种方式才能生效，也就是说， 你必须使用单个长生命周期Session模式，而不能使用 session-per-request-with-detached-objects模式。
有些情况下，只要更改不发生交错，并发修改也是允许的。当你在 的映射中设置optimistic-lock="dirty"，Hibernate在同步的时候将只比较有脏 数据的字段。
在以上所有场景中，不管是专门设置一个版本/时间戳列，还是进行全部字段/脏数据字段比较， Hibernate都会针对每个实体对象发送一条UPDATE（带有相应的 WHERE语句 ）的SQL语句来执行版本检查和数据更新。如果你对关联实体 设置级联关系使用传播性持久化（transitive persistence），那么Hibernate可能会执行不必 要的update语句。这通常不是个问题，但是数据库里面对on update点火 的触发器可能在脱管对象没有任何更改的情况下被触发。因此，你可以在 的映射中，通过设置select-before-update="true" 来定制这一行为，强制Hibernate SELECT这个对象实例，从而保证， 在更新记录之前，对象的确是被修改过。
12.4.悲观锁定(Pessimistic Locking)
用户其实并不需要花很多精力去担心锁定策略的问题。通常情况下，只要为JDBC连接指定一下隔 离级别，然后让数据库去搞定一切就够了。然而，高级用户有时候希望进行一个排它的悲观锁定， 或者在一个新的事务启动的时候，重新进行锁定。
Hibernate总是使用数据库的锁定机制，从不在内存中锁定对象！
类LockMode 定义了Hibernate所需的不同的锁定级别。一个锁定 可以通过以下的机制来设置:
当Hibernate更新或者插入一行记录的时候，锁定级别自动设置为LockMode.WRITE。
当用户显式的使用数据库支持的SQL格式SELECT ... FOR UPDATE 发送SQL的时候，锁定级别设置为LockMode.UPGRADE
当用户显式的使用Oracle数据库的SQL语句SELECT ... FOR UPDATE NOWAIT 的时候，锁定级别设置LockMode.UPGRADE_NOWAIT
当Hibernate在“可重复读”或者是“序列化”数据库隔离级别下读取数据的时候，锁定模式 自动设置为LockMode.READ。这种模式也可以通过用户显式指定进行设置。
LockMode.NONE 代表无需锁定。在Transaction结束时， 所有的对象都切换到该模式上来。与session相关联的对象通过调用update() 或者saveOrUpdate()脱离该模式。
"显式的用户指定"可以通过以下几种方式之一来表示:
调用 Session.load()的时候指定锁定模式(LockMode)。
调用Session.lock()。
调用Query.setLockMode()。
如果在UPGRADE或者UPGRADE_NOWAIT锁定模式下调 用Session.load()，并且要读取的对象尚未被session载入过，那么对象 通过SELECT ... FOR UPDATE这样的SQL语句被载入。如果为一个对象调用 load()方法时，该对象已经在另一个较少限制的锁定模式下被载入了，那 么Hibernate就对该对象调用lock() 方法。
如果指定的锁定模式是READ, UPGRADE 或 UPGRADE_NOWAIT，那么Session.lock()就 执行版本号检查。（在UPGRADE 或者UPGRADE_NOWAIT 锁定模式下，执行SELECT ... FOR UPDATE这样的SQL语句。）
如果数据库不支持用户设置的锁定模式，Hibernate将使用适当的替代模式（而不是扔出异常）。 这一点可以确保应用程序的可移植性。
相关文章 推荐文章
2008-5-13
