樂觀鎖定實際上如何強制重新讀取/更新？

我對樂觀鎖的理解是，它使用表中每條記錄的時間戳來確定記錄的“版本”，這樣當多個程序同時訪問該記錄時，每個記錄的版本都有一個參考.

然後，當執行更新時，時間戳被更新。在送出更新之前，它會第二次讀取記錄上的時間戳。如果它擁有的時間戳（版本）不再是記錄上的時間戳（因為它自第一次讀取以來已被更新），則該過程必須重新讀取整個記錄並將更新應用於它的新版本。

因此，如果我所說的任何內容不正確，請首先為我澄清。但是，假設我在這里或多或少是正確的……

這實際上如何在 RDBMS 中體現出來？這是在應用程序邏輯（SQL 本身）中強制執行的第二次讀取/驗證，還是 DBA 進行的調整參數/配置？

我想我想知道讀取時間戳並在時間戳過時時執行第二次更新的邏輯從何而來。所以我問：應用程序開發人員是強制執行樂觀鎖定，還是由 DBA 強制執行？不管怎樣，怎麼辦？提前致謝！

基本技術非常簡單。當您閱讀記錄時，您會記下版本或時間戳列，例如

Select FooID
     ,Foo
     ,Bar
     ,TS      -- timestamp
 from Foobar
where FooID = @FooID

當您寫出記錄時，您會按時間戳/版本過濾寫入，以便在時間戳/版本發生更改時寫入不會寫入任何內容。這使得寫入原子，例如

update Foo
  set Foo = @foo
     ,Bar = @bar
     ,TS = @timestamp  
where FooID = @FooID
  and ts = @timestamp

select @row_count = @@rowcount  -- specific to t-sql, but this is a system variable
                               -- that holds the number of rows affected by the
if @@rowcount = 0               -- most recent operation.  Other DBMS platforms do
   [deal with outdated record] -- this differently.

這允許應用程序在不打開鎖的情況下進行更新。這對於通過連接池工作的 n 層系統是必要的，並且可以防止過去在兩層客戶端-伺服器系統上常見的一類死鎖。

數據庫中沒有強制執行此操作。這一切都是由應用程序明確完成的。

引用自：https://dba.stackexchange.com/questions/35811