乐观锁和悲观锁

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

l 丢失更新：丢失更新分为两类，
一类是A事务撤销时，把已经提交的B事务的更新数据覆盖了；

时间	取款事务A	转账事务B
T1	开始事务
T2		开始事务
T3	查询账户余额为1000元
T4		查询账户余额为1000元
T5		汇入100元把余额改为1100元
T6		提交事务
T7	取出100元把余额改为900元
T8	撤销事务
T9	余额恢复为1000 元（丢失更新）

另一类是A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失：

时间	转账事务A	取款事务B
T1		开始事务
T2	开始事务
T3		查询账户余额为1000元
T4	查询账户余额为1000元
T5		取出100元把余额改为900元
T6		提交事务
T7	汇入100元
T8	提交事务
T9	把余额改为1100 元（丢失更新）

l 脏读：当一个事务A对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务B也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务B读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的（当事物A发生回滚的时候）。

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

并发控制机制

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

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

乐观锁应用

1. 使用自增长的整数表示数据版本号。更新时检查版本号是否一致，比如数据库中数据版本为6，更新提交时version=6+1,使用该version值(=7)与数据库version+1(=7)作比较，如果相等，则可以更新，如果不等则有可能其他程序已更新该记录，所以返回错误。
2. 使用时间戳来实现.
注：对于以上两种方式,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

commit

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

结论

在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁解决并发问题；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.

参考文档

[1]Concurrent Control http://en.wikipedia.org/wiki/Concurrency_control
[2] Oracle的悲观锁和乐观锁http://space.itpub.net/12158104/viewspace-374745

[3] timestamp应用——乐观锁和悲观锁【转】http://hi.baidu.com/piaokes/blog/item/9b0c6854e4909050564e00b3.html