Hibernate之锁机制

如果需要保证数据访问的排它性，则需对目标数据加“锁”，使其无法被其它程序修改

悲观锁

它指的是对数据被外界修改持保守态度。假定任何时刻存取数据时，都可能有另一个客户也正在存取同一笔数据，为了保持数据被操作的一致性，于是对数据采取了数据库层次的锁定状态，依靠数据库提供的锁机制来实现。

使用悲观锁解决事务并发问题
悲观锁，正如其名，他总是悲观的认为要操作的数据会有并发访问。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
一个典型的依赖数据库的悲观锁调用：select * from account where name=”Erica” for update这条sql语句锁定了account表中所有符合检索条件（name=”Erica”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。悲观锁，也是基于数据库的锁机制实现。
在Hibernate使用悲观锁十分容易，但实际应用中悲观锁是很少被使用的，因为它大大限制了并发性。

使用乐观锁解决事务并发问题
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个”version”字段来实现。

乐观锁的工作原理：读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

Hibernate为乐观锁提供了3种实现：
●基于version
●基于timestamp
●为遗留项目添加添加乐观锁
例如：
一般是通过为数据库表增加一个 “version” 字段来实现（我只知道Oracle是这样，其他的没试过）
个人感觉火车站卖票系统就是乐观锁，查票时查到了脏数据（就是另外一些事务还未提交的数据），看到显示屏上有少量剩余票，但点进去去买又买不到。乐观锁原理其实就是给每一条数据加上时间概念的标识，表明我这条数据是什么时候的，可以理解为是相对时间，就是你所说的建表的时候添加version，然后我去取这条数据，比如version这个时候是0015了，那么我操作完这条数据，要update回去时，又去查一遍这个version值，发现如果还是0015，那么我就放心了，我就可以把version变成0016然后提交，因为在我操作这个过程中没人动他，如果比0015大，那说明有人动过他了，我就选择不操作这条数据了。

还有一种方式是直接用时间字段表示，也就是时间戳，就是我提交这条数据时，之前拿到数据时的那个时间值一定要等于我要提交之前这个时刻点的时间值，如果小于当前数据的这个时间戳，那么肯定是有事务在我之前提交了。

其实乐观锁是解决高并发性能的办法。悲观锁更安全，但是并发性能太差，特别是有长事务的时候，并发事务会排很长的队

Hibernate对数据的锁机制：
Hibernate可以利用Query或者Criteria的setLockMode()方法来设定要锁定的表或列(Row)及其锁定模式：

●LockMode.NONE：无锁机制；在事务结束时，所有的对象都切换到该模式上来。与session相关联的对象通过调用update()或者saveOrUpdate()脱离该模式
●LockMode.WRITE：当更新或者插入一行记录的时候，锁定级别自动设置为LockMode.WRITE
●LockMode.READ:当Hibernate在“可重复读”或者是“序列化”数据库隔离级别下读取数据的时候，锁定模式自动设置为LockMode.READ。这种模式也可以通过用户显式指定进行设置。
●LockMode.UPGRADE:利用数据库的for update子句加锁
●LockMode.UPGRADE_NOWAIT:利用oracle的特定实现for update nowait子句实现

参考博客：
http://blog.csdn.net/a19881029/article/details/20665663
http://blog.csdn.net/crazyitlhs/article/details/49446453
http://www.cnblogs.com/sias/p/4166570.html