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

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)選項,在查詢記錄的時候咱們就對記錄加上了更新鎖,表示咱們即將對此記錄進行更新. 注意更新鎖和共享鎖是不衝突的,也就是其餘用戶還能夠查詢此表的內容,可是和更新鎖和排它鎖是衝突的.因此其餘的更新用戶就會阻塞.
結論
在實際生產環境裏邊,若是併發量不大且不容許髒讀,能夠使用悲觀鎖解決併發問題;但若是系統的併發很是大的話,悲觀鎖定會帶來很是大的性能問題,因此咱們就要選擇樂觀鎖定的方法.
參考文檔
[2] Oracle的悲觀鎖和樂觀鎖 http://space.itpub.net/12158104/viewspace-374745
[3] timestamp應用——樂觀鎖和悲觀鎖【轉】 http://hi.baidu.com/piaokes/blog/item/9b0c6854e4909050564e00b3.html
相關文章
相關標籤/搜索