第 10 章 事务和并行（Transactions And Concurrency） - Hibernate reference 2.1.8 ga 正式版中文参考手册

SessionFactory的创建需要耗费大量资源，它是线程安全（threadsafe）的对象，在应用中它被所有线程共享。而Session的创建耗费资源很少，它不是线程安全的对象，对于一个简单商业过程（business process），它应该只被使用一次，然后被丢弃。举例来说，当Hibernate在基于servlet的应用中，servlet能够以下面的方式得到SessionFactory。

SessionFactory sf = (SessionFactory)getServletContext().getAttribute("my.session.factory");

每次调用SessionFactory的service方法能够生成一个新的Session对象，然后调用Session的flush()，调用commit()提交它的连接，调用close()关闭它，最终丢弃它。(SessionFactory可能被保存在JNDI或者一个静态的单例（Singleton）辅助变量中。）

在无状态的session bean中，可以同样使用类似的方法。bean在setSessionContext()中得到SessionFactory的实例，每个商业方法会生成一个Session对象，调用它的flush()和close()，当然，应用不应该commit()connection. (把它留给JTA.在容器管理的事务中，数据库连接会自动完成事务。)

我们用上述方法使用Hibernate 的Transaction API，对Transaction执行一次commit()会把所有状态同步，把底层的数据库连接提交(对JTA 事务会特殊处理。)

这里需要理解flush()的含义。 flush()将持久化存储与内存中的变化进行同步，但不是将内存的变化与持久化存储进行同步。注意对所有的Hibernate JDBD 连接/事务来说，其隔离级别将施加于所有的Hibernate执行的操作之上！

接下来的几小节将讨论利用版本化的方法来确保事务原子性，这些“高级”方法需要小心使用。

在创建Hibernate会话（Session）时，你应该留意以下的实践（practices）：

程序可能在两批单元操作中并发访问同一个对象的持久化状态。不管怎样，持久化类的一个实例不可能在两个Session中共享。所以有两种不同的辨别方式：

对于依附于某个特定Session的对象，两种辨别方式是等价的。然而，当程序可能在两个不同的session中并发访问“同一个”（持久化辨别）商业对象时，两个实例（对于JVM辨别来说）却可能是“不同”的。

这种方式把关于并发的头疼问题留给了Hibernate和数据库。程序不需要对任何商业对象进行同步，只要程序坚持每个Session一个线程，或者对象辨别的策略（在一个Session重，程序可以安全的使用==来比较对象）。

许多商业过程需要一系列与用户进行交互的过程，数据库访问穿插在这些过程中。对于web和企业应用来说，跨一个用户交互过程的数据事务是不可接受的。

维护各商业事务间的隔离（isolocation）就成为应用层的部分责任，我们把这种过程称为长时间运行的应用事务（application transaction）。单一的应用事务可能跨越多个数据库事务。如果这些数据库事务中只有一个（最后一个）保存了被修改的数据，其他事务只是简单地读数据，则这个应用事务就是原子性的。

唯一满足高并发性以及高可扩展性的方法是使用带有版本化的乐观并发控制。Hibernate为使用乐观并发控制的代码提供了三种可能的方法。

// foo is an instance loaded earlier by the Session
session.reconnect();
foo.setProperty("bar");
session.flush();
session.connection().commit();
session.disconnect();

// foo is an instance loaded by a previous Session
foo.setProperty("bar");
session = factory.openSession();
session.saveOrUpdate(foo);
session.flush();
session.connection().commit();
session.close();

// foo is an instance loaded by a previous Session
session = factory.openSession();
int oldVersion = foo.getVersion();
session.load( foo, foo.getKey() );
if ( oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
foo.setProperty("bar");
session.flush();
session.connection().commit();
session.close();

The first approach described above is to maintain a single Session for a whole business process thats spans user think time. (For example, a servlet might keep a Session in the user's HttpSession.) For performance reasons you should

上面提到的第一种方法是对于对一个用户的一次登录产生的整个商业过程维护一个Session。（举例来说，servlet有可能会在用户的HttpSession中保留一个Session）。为性能考虑，你必须

Session.disconnect()方法会断开会话与JDBC的连接，把连接返还给连接池（除非是你自己提供这个连接的）。

Session.reconnect()方法会得到一个新的连接（你也可以自己提供一个），重新开始会话。在重新连接后，你可以通过对任何可能被其它事务更新的对象调用Session.lock()方法，来强迫对你没有更新的数据进行版本检查。你不需要对正在更新的数据调用lock()。

这是一个例子：

SessionFactory sessions;
List fooList;
Bar bar;
....
Session s = sessions.openSession();

Transaction tx = null;
try {
    tx = s.beginTransaction();

    fooList = s.find(
    	"select foo from eg.Foo foo where foo.Date = current date"
        // uses db2 date function
    );
    bar = (Bar) s.create(Bar.class);

    tx.commit();
}
catch (Exception e) {
    if (tx!=null) tx.rollback();
    s.close();
    throw e;
}
s.disconnect();

接下来：

s.reconnect();

try {
    tx = s.beginTransaction();

    bar.setFooTable( new HashMap() );
    Iterator iter = fooList.iterator();
    while ( iter.hasNext() ) {
        Foo foo = (Foo) iter.next();
        s.lock(foo, LockMode.READ);    //check that foo isn't stale
        bar.getFooTable().put( foo.getName(), foo );
    }

    tx.commit();
}
catch (Exception e) {
    if (tx!=null) tx.rollback();
    throw e;
}
finally {
    s.close();
}

从上面的例子可以看到Transaction和Session之间是多对一的关系。一个Session表示了应用程序与数据库之间的一个对话，Transaction把这个对话分隔成一个个在数据库级别具有原子性的单元。

用户不需要在锁定策略上花费过多时间，通常我们可以对JDBC连接选定一种隔离级别（isolationn level），然后让数据库完成所有的工作。高级用户可能希望得到悲观锁定或者在新的事务开始时重新得到锁。

Hibernate一直都会使用数据库的锁定机制,而不会在内存中锁定对象。

LockMode类定义了Hibernate需要的不同的锁级别。锁由以下的机制得到：

“明确的用户请求”会以下的几种方式出现：

如果在调用Session.load()时指定了UPGRADE或者UPGRADE_NOWAIT，并且请求的对象还没有被会话调入，那么这个对象会以SELECT ... FOR UPDATE的方式调入。如果调用load()在一个已经调入的对象，并且这个对象调入时的锁级别没有请求时来得严格，Hibernate会对这个对象调用lock()。

Session.lock()会执行版本号检查的特定的锁模式是：READ，UPGRADE或者UPGRADE_NOWAIT。（在UPGRADE或者UPGRADE_NOWAIT，SELECT ... FOR UPGRADE使用的情况下。）

如果数据库不支持所请求的锁模式，Hibernate将会选择一种合适的受支持的锁模式替换（而不是抛出一个异常）。这确保了应用具有可移植性。