使用 Spring、MyBatis 和 OracleDB 的多個應用服務器的 Java 數據庫事務

Question

在 Java 中使用多個應用程序服務器執行數據庫事務時遇到問題。

設想：

有兩張桌子。 LOCKED_FILE_INFO 和 FILE_INFO

1：FILE_INFO表包含FILEID(Primary), FILENAME, USERID, FILETYPE, QTY等文件的信息

2：LOCKED_FILE_INFO表包含FILEID(Primary)、FILENAME、TimeOfLock等信息

3: FILE_INFO & LOCKED_FILE_INFO 表中可以有多個用戶要輸入的文件列表或單個文件。

4：之前，在 FILE_INFO 中輸入條目，我們將在 LOCKED_FILE_INFO 中鎖定該特定文件，以便只有 1 個用戶可以鎖定該 FILE 信息，然后進入 FILE_INFO 表。

5：如果多個用戶對同一個文件執行輸入，他們會得到-“信息已經被另一個用戶鎖定”。

邏輯：

a: 在 FILE_INFO 表中進行條目之前，我們將檢查 LOCKED_FILE_INFO 表以驗證文件（例如：file100）是否已經存在

b：如果文件已經存在（LOCKED）-顯示-“信息已經被另一個用戶鎖定”。

c：如果文件不存在（NOT LOCKED），則在LOCK_FILE_INFO中做一個條目，這樣其他用戶就不能鎖定文件，只有成功的用戶才能進入FILE_INFO表。

d：一旦我們進入FILE_INFO表，就從LOCKED_FILE_INFO表中刪除Locked文件

問題：

當多個用戶嘗試在 LOCK_FILE_INFO 中同時鎖定同一個文件時，我收到 PRIMARY_KEY 違規異常 這在我運行單個應用程序服務器時不會發生。 這僅在運行多個應用程序服務器（至少 5 個）時發生

我嘗試了幾種方法 a：使用同步 b：使用事務級隔離

但是，當多個用戶同時嘗試插入 LOCKED_FILE_INFO 表時，我仍然無法鎖定特定文件。 但是，如果有至少 1 秒的延遲，那么我根本沒有遇到問題。

任何建議將不勝感激。 謝謝 ！

Answer 1

出現問題是因為邏輯中存在競爭條件。 即，不同用戶進行的兩個並發事務可能會成功執行步驟a檢查並嘗試插入到LOCK_FILE_INFO 。 顯然只有一個成功，第二個會失敗。

當並行度發生變化時（當並發運行的進程數量發生變化時），正在運行的進程中發生的單個事件的時間也會發生變化。 所以這種並發場景的行為可能會有所不同。

您有多種選擇來解決您遇到的問題。

處理主鍵違規

您可以捕獲異常並顯示文件已被鎖定的消息。 在這種情況下，檢查鎖定記錄是否存在是沒有意義的。 也就是說，您不需要執行步驟a 。 只需插入一個鎖記錄，如果有主鍵沖突 - 鎖已經存在。

鎖定更新

使用插入鎖定的問題是檢測沖突的唯一原因是通過約束違規。 如果您更改鎖定策略，以便改為更新記錄。

首先，無論是始終創建一個記錄文件LOCK_FILE_INFO當記錄FILE_INFO創建或存儲信息有關鎖FILE_INFO表（ timeOfLock欄應該是足夠的，如果是NULL文件未鎖定）。

需要加鎖時，執行更新查詢即可

update LOCK_FILE_INFO
set TimeOfLock = now()
where TimeOfLock is NULL
   AND FILEID = some_id

然后，您需要檢查記錄是否已更新。 每個修改語句都會返回更新記錄的數量。 要獲得此數字，只需從 mybatis 映射器中的插入方法返回int 。 如果記錄被更新，則該事務成功獲取鎖，否則無法獲取文件鎖（要么已經被鎖住，要么文件已被刪除，見下文）。

請注意，這取決於some_id是正確的文件 ID 的事實。 可能會在您執行更新語句之前刪除文件。 在這種情況下，看起來文件被鎖定了，但實際上它已經消失了。 實際上，這不是問題，因為在鎖定失敗后，您通常需要刷新 UI 以顯示文件的更新狀態，在這種情況下，您會檢測到該文件已消失。

不起作用的選項

通過同步同步

使用synchronized關鍵字（如果正確完成）的synchronized僅對單進程情況有幫助，因為在這種情況下，同步是使用進程內部的鎖完成的。 如果有多個 JVM 進程，每個進程都有自己的鎖，同步將無法按預期工作。

序列化隔離級別

序列化隔離級別在這種情況下不起作用，因為它無法幫助插入。 如果您在兩個事務中插入兩個具有相同鍵的記錄，無論隔離級別如何，您都會得到相同的主鍵違規。