樂觀鎖和悲觀鎖

爲何須要鎖（併發控制）？

在多用戶環境中，在同一時間可能會有多個用戶更新相同的記錄，這會產生衝突。這就是著名的併發性問題。

典型的衝突有：

l 丟失更新：一個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如：用戶A把值從6改成2，用戶B把值從2改成6，則用戶A丟失了他的更新。

l 髒讀：當一個事務讀取其它完成一半事務的記錄時，就會發生髒讀取。例如：用戶A,B看到的值都是6，用戶B把值改成2，用戶A讀到的值仍爲6。

爲了解決這些併發帶來的問題。 咱們須要引入併發控制機制。

併發控制機制

悲觀鎖：假定會發生併發衝突，屏蔽一切可能違反數據完整性的操做。[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)選項,在查詢記錄的時候咱們就對記錄加上了更新鎖,表示咱們即將對此記錄進行更新. 注意更新鎖和共享鎖是不衝突的,也就是其餘用戶還能夠查詢此表的內容,可是和更新鎖和排它鎖是衝突的.因此其餘的更新用戶就會阻塞.

結論

在實際生產環境裏邊,若是併發量不大且不容許髒讀，能夠使用悲觀鎖解決併發問題；但若是系統的併發很是大的話,悲觀鎖定會帶來很是大的性能問題,因此咱們就要選擇樂觀鎖定的方法.