乐观锁和悲观锁

为何须要锁（并发控制）？

在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。

典型的冲突有：

• 丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改成2，用户B把值从2改成6，则用户A丢失了他的更新。
•  脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改成2，用户A读到的值仍为6。

为了解决这些并发带来的问题。 咱们须要引入并发控制机制。

并发控制机制

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操做。[1]

乐观锁：假设不会发生并发冲突，只在提交操做时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。

乐观锁应用

1. 使用自增加的整数表示数据版本号。更新时检查版本号是否一致，好比数据库中数据版本为6，更新提交时version=6+1,使用该version值(=7)与数据库version+1(=7)做比较，若是相等，则能够更新，若是不等则有可能其余程序已更新该记录，因此返回错误。
2. 使用时间戳来实现

注：对于以上两种方式,Hibernate自带实现方式：在使用乐观锁的字段前加annotation: @Version , Hibernate在更新时自动校验该字段。

注：对于以上两种方式,Hibernate自带实现方式：在使用乐观锁的字段前加annotation: @Version , Hibernate在更新时自动校验该字段。

悲观锁应用

    须要使用数据库的锁机制，好比SQL SERVER 的TABLOCKX（排它表锁） 此选项被选中时，SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其余进程读取或修改表中的数据。

SqlServer中使用

Begin Tran
select top 1 @TrainNo=T_NO
         from Train_ticket   with (UPDLOCK)   where S_Flag=0

      update Train_ticket
         set T_Name=user,
             T_Time=getdate(),
             S_Flag=1
         where T_NO=@TrainNo
commi

      咱们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候咱们就对记录加上了更新锁,表示咱们即将对此记录进行更新. 注意更新锁和共享锁是不冲突的,也就是其余用户还能够查询此表的内容,可是和更新锁和排它锁是冲突的.因此其余的更新用户就会阻塞.

结论

      在实际生产环境里边,若是并发量不大且不容许脏读，能够使用悲观锁解决并发问题；但若是系统的并发很是大的话,悲观锁定会带来很是大的性能问题,因此咱们就要选择乐观锁定的方法.

参考文档

[1]Concurrent Control http://en.wikipedia.org/wiki/Concurrency_control

[2] Oracle的悲观锁和乐观锁http://space.itpub.net/12158104/viewspace-374745