hibernate之乐观锁（Optimistic Locking）
bleach00 2011-01-06
相对于悲观锁，乐观锁采取了更加宽松的加锁机制，悲观锁大多数是依赖于数据库，如果对于一个长事务来说，这样的开销会很大！
如：在银行系统中，一个人想从银行取钱，他的公司正好在这个时候往他的卡里打钱，如果使用悲观锁的话，会将它的帐号暂时锁死，一个人还好，如果要是有成千上万个巧合呢？这样的话，银行的数据库的压力会很大；
乐观锁机制在一定程度上解决了这个问题，乐观锁，大多是基于数据版本（version）记录机制实现，何为数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现；
读取数据时，将版本号一同读出，之后更新时，对此版本号加1。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息化时，如果提交的数据版本号大于数据库表当前版本号，则予更新，否则认为是过期数据；
回到银行的例子中：那个人取了2000；当取钱的操作执行完后将数据版本号＋1（version＝2）；公司也往里打了3000，将版本号＋1（version=2）；公司打钱的操作提交时发现有相同的版本号，那么这个操作被驳回；
从例子中可以看出，乐观锁机制避免了长事务中的数据库加锁开销，大大提升了并发量下的系统整体性能表现；
需要注意的是：乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如银行的例子，由于乐观锁机制在我们系统中实现，来自系统外部的用户余额更新操作不受我们影响，因此可能会造成非法数据被更新到数据库中；
Hibernate在其数据访问引擎上内置了乐观锁实现，如果不用考虑外部系统对数据库更新操作，利用hibernate提供的透明化乐观锁实现，会简洁！
Hibernate中使用乐观锁：
<class name="TUser" table="t_user" optimistic-lock="version">
optimistic-lock有如下可选取值：
- none 无乐观锁
- version 通过版本机制实现乐观锁
- dirty 通过检查发生变动过的属性实现乐观锁
- all 通过检查所有属性实现乐观锁
其中Version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，也是Hibernate中，目前唯一在实体对象脱离Session发生修改的情况下依然有效的锁机制。这种方法使用较多！
<version name="version" column="version" type="integer"></version>
version节点必须出现id节点后；
