本頁面說明交易資料爭用、可序列化能力，以及 和隔離機制如需交易程式碼範例，請參閱 交易和批次寫入。
交易與資料爭用
交易成功時，交易所擷取的文件 都必須由交易外的作業保持不變。如有其他 作業嘗試變更其中一份文件，這項作業進入 與交易的資料爭用狀態
- 資料爭用
- 兩個以上的作業互相競爭控制同一份文件時。例如： 一項交易可能需要文件保持一致 作業會嘗試更新該文件的欄位值。
Cloud Firestore 會在 作業。Cloud Firestore 用戶端程式庫 會自動重試因資料爭用而失敗的交易。執行 重試次數有限，交易作業失敗並傳回錯誤 訊息：
ABORTED: Too much contention on these documents. Please try again.
在決定要失敗或延遲的作業時，行為會因為 用戶端程式庫
行動/網頁 SDK 採用開放式並行 控制項
伺服器用戶端程式庫會使用惡意並行控制。
行動/網頁 SDK 中的資料爭用
行動/網頁 SDK (Apple 平台、Android、Web、C++) 採用最佳化並行控制項， 解決資料爭用問題
- 最佳化並行控管機制
- 根據以下假設：資料爭用不太可能或 確保資料庫鎖定的效率最佳化交易不使用資料庫 ，防止其他作業變更資料。
行動/網頁 SDK 採用樂觀並行控制項，因為這類 SDK 能在 並在有高延遲和不穩定的網路連線環境中執行。上鎖中 位於高延遲環境中的文件會導致過多資料爭用 失敗。
在 Mobile/Web SDK 中，交易會追蹤您閱讀的所有文件 實際流程交易僅完成其寫入作業 表示這些文件並未在交易執行期間變更。如果有任何 文件已變更，交易處理常式會重試交易。如果 重試數次後，交易將無法取得簡潔結果 資料。
伺服器用戶端程式庫中的資料爭用
伺服器用戶端程式庫 (C#、Go、Java、Node.js、PHP、Python、Ruby) 會使用 悲觀並行控制可解決資料爭用情形。
- 悲觀並行控制
- 根據以下假設：資料爭用可能會發生的情況。悲觀 交易會使用資料庫鎖定功能，避免其他作業修改資料。
伺服器用戶端程式庫會使用惡意並行控制，因為 假設延遲時間短， 且連線至資料庫也很穩定。
在伺服器用戶端程式庫中，交易會鎖定其文件 讀取。交易鎖定文件，會封鎖其他交易。 「批次寫入」和非交易式寫入變更該文件A 罩杯 交易會在提交時解除文件鎖定。此外， 如果因任何原因而逾時或失敗，就會釋出鎖定。
當交易鎖定文件時，其他寫入作業必須等候 藉此解除鎖定。交易取得鎖定， 依時間順序排列。
可序列化隔離
交易之間的資料爭用與資料庫隔離密切相關 級別。資料庫的隔離等級可說明系統的程度 可處理並行作業之間的衝突。衝突來自 資料庫的需求條件如下：
- 交易需要準確且一致的資料。
- 為了有效率地使用資源，資料庫會並行執行作業。
在隔離等級低的系統中，交易內的讀取作業 可能會從並行輸出中的未修訂變更中讀取不正確的資料 作業。
可序列化隔離定義最高隔離等級。可序列化 表示：
- 您可以假設資料庫會連續執行交易。
- 並行作業中的未修訂變更不會影響交易。
即使資料庫需多次執行 就能同時進行交易資料庫必須導入並行控管機制 可解決無法確保此保證的衝突。
Cloud Firestore 保證可序列化隔離交易。 Cloud Firestore 中的交易會序列化，並藉由修訂版本區隔 讓應用程式從可以最快做出回應的位置 回應使用者要求
可序列化隔離 (依修訂版本)
Cloud Firestore 會為每筆交易指派一個修訂版本時間 只會處理一個時間點當 Cloud Firestore 修訂交易的 可以假設 交易確切在修訂時間進行。
實際執行交易需要一段時間。藉此在 VM 中 交易會在修訂時間之前開始，而 作業可能會重疊Cloud Firestore 維護可序列化隔離 並保證：
- Cloud Firestore 會按照修訂時間依序修訂交易。
- Cloud Firestore 會將交易與並行執行 來處理較晚的修訂
如果是並行作業之間發生資料爭用的情形， Cloud Firestore 使用樂觀和悲觀的並行控管機制來解決爭用情況。
在交易中隔離
交易隔離也適用於交易中的寫入作業。 交易內部的查詢和讀取不會查看先前寫入的結果 「交易檢查」機制即使您在 交易中的所有文件都會傳回 ，再進行交易寫入作業。 如果文件不存在，讀取作業不會傳回任何結果。
資料爭用問題
如要進一步瞭解資料爭用情形和解決方式，請參閱疑難排解頁面。