共享鎖&排它鎖 || 樂觀鎖&悲觀索

1.共享鎖只用於表級，排他鎖用於行級。

2.加了共享鎖的對象，能夠繼續加共享鎖，不能再加排他鎖。加了排他鎖後，不能再加任何鎖。

3.好比一個DML操做，就要對受影響的行加排他鎖，這樣就不容許再加別的鎖，也就是說別的會話不能修改這些行。同時爲了不在作這個DML操做的時候，有別的會話執行DDL，修改表的定義，因此要在表上加共享鎖，這樣就阻止了DDL的操做。

4.當執行DDL操做時，就須要在全表上加排他鎖

 

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

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

典型的衝突有：

 

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)選項,在查詢記錄的時候咱們就對記錄加上了更新鎖,表示咱們即將對此記錄進行更新. 注意更新鎖和共享鎖是不衝突的,也就是其餘用戶還能夠查詢此表的內容,可是和更新鎖和排它鎖是衝突的.因此其餘的更新用戶就會阻塞.

結論

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

參考文檔

[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