11.3. 乐观并发控制(Optimistic concurrency control)

唯一能够同时保持高并发和高可伸缩性的方法就是使用带版本化的乐观并发控制。版本检查使用版本号、 或者时间戳来检测更新冲突(并且防止更新丢失)。Hibernate为使用乐观并发控制的代码提供了三种可 能的方法,应用程序在编写这些代码时,可以采用它们。我们已经在前面应用程序对话那部分展示了 乐观并发控制的应用场景,此外,在单个数据库事务范围内,版本检查也提供了防止更新丢失的好处。

11.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 属性使用 <version>来映射,如果对象 是脏数据,在同步的时候,Hibernate会自动增加版本号。

当然,如果你的应用是在一个低数据并发环境下,并不需要版本检查的话,你照样可以使用 这种方式,只不过跳过版本检查就是了。在这种情况下,最晚提交生效last commit wins)就是你的长对话的默认处理策略。 请记住这种策略可能会让应用软件的用户感到困惑,因为他们有可能会碰上更新丢失掉却没 有出错信息,或者需要合并更改冲突的情况。

Clearly, manual version checking is only feasible in very trivial circumstances and not practical for most applications. Often not only single instances, but complete graphs of modified objects have to be checked. Hibernate offers automatic version checking with either an extended Session or detached instances as the design paradigm.

11.3.2. 扩展周期的session和自动版本化

单个 Session实例和它所关联的所有持久化对象实例都被用于整个 对话,这被称为session-per-conversation。Hibernate在同步的时候进行对象实例的版本检查,如果检测到并发修 改则抛出异常。由开发人员来决定是否需要捕获和处理这个异常(通常的抉择是给用户 提供一个合并更改,或者在无脏数据情况下重新进行业务对话的机会)。

在等待用户交互的时候, Session 断开底层的JDBC连接。这种方式 以数据库访问的角度来说是最高效的方式。应用程序不需要关心版本检查或脱管对象实例 的重新关联,在每个数据库事务中,应用程序也不需要载入读取对象实例。

// foo is an instance loaded earlier by the old session
Transaction t = session.beginTransaction(); // Obtain a new JDBC connection, start transaction

foo.setProperty("bar");

session.flush();    // Only for last transaction in conversation
t.commit();         // Also return JDBC connection
session.close();    // Only for last transaction in conversation

foo对象知道它是在哪个Session中被装入的。在一个旧session中开启一个新的数据库事务,会导致session获取一个新的连接,并恢复session的功能。将数据库事务提交,使得session从JDBC连接断开,并将此连接交还给连接池。在重新连接之后,要强制对你没有更新的数据进行一次版本检查,你可以对所有可能被其他事务修改过的对象,使用参数LockMode.READ来调用Session.lock()。你不用lock任何你正在更新的数据。一般你会在扩展的Session上设置FlushMode.MANUAL,因此只有最后一个数据库事务循环才会真正的吧整个对话中发生的修改发送到数据库。因此,只有这最后一次数据库事务才会包含flush()操作,然后在整个对话结束后,还要close()这个session。

如果在用户思考的过程中,Session因为太大了而不能保存,那么这种模式是有 问题的。举例来说,一个HttpSession应该尽可能的小。由于 Session是一级缓存,并且保持了所有被载入过的对象,因此 我们只应该在那些少量的request/response情况下使用这种策略。你应该只把一个Session用于单个对话,因为它很快就会出现脏数据。

(注意,早期的Hibernate版本需要明确的对Session进行disconnec和reconnect。这些方法现在已经过时了,打开事务和关闭事务会起到同样的效果。)

此外,也请注意,你应该让与数据库连接断开的Session对持久层保持 关闭状态。换句话说,在三层环境中,使用有状态的EJB session bean来持有Session, 而不要把它传递到web层(甚至把它序列化到一个单独的层),保存在HttpSession中。

扩展session模式,或者被称为每次对话一个session(session-per-conversation), 在与自动管理当前session上下文联用的时候会更困难。你需要提供你自己的CurrentSessionContext实现。请参阅Hibernate Wiki以获得示例。

11.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();

Again, Hibernate will check instance versions during flush, throwing an exception if conflicting updates occurred.

如果你确信对象没有被修改过,你也可以调用lock() 来设置 LockMode.READ(绕过所有的缓存,执行版本检查),从而取 代 update()操作。

11.3.4. 定制自动版本化行为

对于特定的属性和集合,通过为它们设置映射属性optimistic-lock的值 为false,来禁止Hibernate的版本自动增加。这样的话,如果该属性 脏数据,Hibernate将不再增加版本号。

Legacy database schemas are often static and can't be modified. Or, other applications might also access the same database and don't know how to handle version numbers or even timestamps. In both cases, versioning can't rely on a particular column in a table. To force a version check without a version or timestamp property mapping, with a comparison of the state of all fields in a row, turn on optimistic-lock="all" in the <class> mapping. Note that this conceptually only works if Hibernate can compare the old and new state, i.e. if you use a single long Session and not session-per-request-with-detached-objects.

有些情况下,只要更改不发生交错,并发修改也是允许的。当你在<class> 的映射中设置optimistic-lock="dirty",Hibernate在同步的时候将只比较有脏 数据的字段。

In both cases, with dedicated version/timestamp columns or with full/dirty field comparison, Hibernate uses a single UPDATE statement (with an appropriate WHERE clause) per entity to execute the version check and update the information. If you use transitive persistence to cascade reattachment to associated entities, Hibernate might execute unnecessary updates. This is usually not a problem, but on update triggers in the database might be executed even when no changes have been made to detached instances. You can customize this behavior by setting select-before-update="true" in the <class> mapping, forcing Hibernate to SELECT the instance to ensure that changes did actually occur, before updating the row.