交易中的資料爭用情況

本頁說明交易資料爭用、可序列化和隔離。如需交易程式碼範例，請參閱交易和批次寫入作業。

交易和資料爭用

如要讓交易成功，交易讀取作業擷取的檔案不得由交易外部的作業修改。如果其他作業嘗試變更其中一個文件，該作業就會與交易發生資料爭用。

Firestore 會延遲或失敗其中一項作業，以解決資料爭用問題。如果交易因資料爭用而失敗，Firestore 用戶端程式庫會自動重試。經過有限次數的重試後，交易作業會失敗並傳回錯誤訊息：

ABORTED: Too much contention on these documents. Please try again.

決定要讓哪個作業失敗或延遲時，行為取決於並行控制項的類型。

並行模式是可設定的資料庫選項。 Firestore 支援下列並行模式：

PESSIMISTIC：悲觀並行控制項會假設資料爭用可能發生，悲觀交易會使用資料庫鎖定，防止其他作業修改資料。

採用悲觀並行控制時，交易會鎖定讀取的文件。交易對文件進行鎖定後，其他交易、批次寫入作業和非交易寫入作業就無法變更該文件。交易會在提交時釋出文件鎖定。如果逾時或因任何原因失敗，也會釋放鎖定。

交易鎖定文件後，其他寫入作業必須等待交易釋放鎖定。交易會依時間順序取得鎖定。
OPTIMISTIC：樂觀並行控制會假設資料爭用不太可能發生，或持有資料庫鎖定並非有效率的做法。樂觀交易不會使用資料庫鎖定功能，禁止其他作業變更資料

透過最佳化並行控制，交易會追蹤您在交易中讀取的所有文件。只有在交易執行期間，這些文件都沒有變更，交易才會完成寫入作業。如果任何文件發生變更，交易處理常式會重試交易。如果交易在幾次重試後仍無法取得乾淨結果，就會因資料爭用而失敗。

Standard 版的預設值為 PESSIMISTIC。Enterprise 版本的預設值為 OPTIMISTIC。不過，行為也取決於用戶端程式庫類型：

行動和網頁 SDK 會使用文件版本的寫入前置條件，模擬最佳化並行交易。無論資料庫的並行模式設定為何，都會發生這項模擬作業。行動和網頁 SDK 不會使用內建交易功能，因此即使資料庫並行模式設為 PESSIMISTIC，行動用戶端仍會以樂觀模式運作。

行動/網頁 SDK 使用樂觀並行控制，因為這些 SDK 可以在高延遲和網路連線不穩定的環境中運作。在高延遲環境中鎖定文件會導致過多資料爭用失敗。

伺服器用戶端程式庫 (C#、Go、Java、Node.js、PHP、Python、Ruby) 使用內建交易功能。這些交易會使用資料庫層級的並行模式設定，預設值則取決於版本：

交易之間的資料爭用情況與資料庫隔離等級密切相關。資料庫的隔離等級說明系統處理並行作業之間衝突的程度。衝突來自下列資料庫需求：

在隔離層級較低的系統中，交易內的讀取作業可能會從並行作業中未提交的變更讀取不準確的資料。

可序列化隔離定義最高隔離等級。可序列化隔離層級是指：

即使資料庫平行執行多筆交易，這項保證也必須成立。資料庫必須實作並行控制項，以解決會破壞這項保證的衝突。

Firestore 保證交易的可序列化隔離。Firestore 中的交易會依提交時間序列化及隔離。

Firestore 會為每筆交易指派提交時間，代表單一時間點。當 Firestore 將交易的變更提交至資料庫時，您可以假設交易中的所有讀取和寫入作業，都發生在提交時間。

實際執行交易需要一段時間。交易的執行作業會在提交時間前開始，且多項作業的執行作業可能會重疊。Firestore 會維持可序列化隔離，並保證：

交易隔離也適用於交易內的寫入作業。交易內部的查詢和讀取作業不會看到先前在該交易中寫入的結果，即使您在交易中修改或刪除文件，該交易中的所有文件讀取作業都會傳回修訂時的文件版本，也就是交易寫入作業之前的文件版本。如果當時文件不存在，讀取作業不會傳回任何內容。

如要進一步瞭解資料爭用和解決方式，請參閱疑難排解頁面。