锁（locking）

<!----><!----> <!---->

《深入浅出 Hibernate 》一书（作者：夏昕 曹晓钢 唐勇 2005 年版）

第 5 章 Hibernate 高 级 特性

5.1.5 事 务 管理

锁 （ locking ）

 

关于悲观锁和乐观锁这一部分，作者思路清晰，分析透彻，文笔流畅，举的例子也通俗易懂，令人拍案叫绝！绝对要赞一个！

 

下面，我补充一个关于悲观锁的测试例子程序：

 

写个测试类，里面写两个测试方法（代码一样，都是从数据库中 load 出数据，打印出来，接着 set 一个新的余额，最后 commit ），分别用于模拟两个用户对数据库中账户余额表的并发操作。假设此时某账户余额是 100 元人民币，方法 1 和方法 2 都想进行减 20 的操作。

 

先 debug 运行测试方法 1 的代码，从数据库账户余额表中以悲观锁模式把数据 load 出来，接着执行更新操作（执行了 set 方法，将余额重新设置了（从 100 变成了 80 ），此时至于要不要显示地调用 update 方法，则无所谓，因为 Persistent 状态的对象，在 commit 时会自动进行更新的），在执行 commit 方法之前，停住（此时方法 1 没有 commit ，没有提交事务，也就没有释放掉对这条记录的锁）；

 

再来直接运行测试方法 2 。此时会发现测试方法 2 就发了一条 select 语句（想从数据库中查出这条记录），然后就停在那边了，僵住了，在等着，等什么呢？方法 2 在等待方法 1 放掉对这条记录的锁，因为此时这条数据还被方法 1 锁着，此时方法 2 对这条数据进行不了任何操作；

 

再去继续运行方法 1 ，将 commit 方法执行完成后，到数据库中确认，会发现此时的数据已经是方法 1 执行之后的结果了（账户余额是 80 ）；

 

再去运行方法 2 ，立马运行通过了，此时再到数据库中确认，会发现此时的数据已经是方法 2 （在方法 1 执行后的基础上）执行后之后的结果（账户余额是 60 ）。

 

由此可见，使用悲观锁机制能解决“更新丢失”的问题。至于悲观锁的缺点，我就不重复了，作者已经分析得很透彻了。

关于乐观锁的实现，也可以采用时间戳机制，实现原理（将试图向数据库提交的记录的时间戳和数据库中该记录的当前时间戳进行比较）和使用最为广泛的数据版本机制 Version 也差不了多少。但显然，我们应该优先重点掌握 Version 方式。

 

还有一点，原文中提到这样一句“ 注意 ,version 节点必须出现在 ID 节点之后。”

 

说明一下，这个顺序是在 DTD文件中定义的，受其约束。