例外狀況處理和重試

交易由於無法解決的衝突或鎖定等待逾時而取消時，Amazon Neptune 會以 ConcurrentModificationException 回應。如需詳細資訊，請參閱引擎錯誤代碼。根據最佳實務，用戶端應一律截獲和處理這些例外狀況。

在許多情況下，當 ConcurrentModificationException 執行個體數量很低時，以指數退避為基礎的重試機制也很適合做為處理它們的方式。在這類重試方法中，重試次數和等待時間上限通常取決於交易的大小上限和持續時間。

不過， 如果您的應用程式具有高度並行更新工作負載，而且您觀察到大量 ConcurrentModificationException 事件，則您或許能夠修改應用程式，以減少發生衝突之並行修改的數量。

例如，考量有一個應用程式經常更新一組頂點，並使用多個並行執行緒進行這些更新，以最佳化寫入輸送量。如果每個執行緒持續執行更新一或多個節點屬性的查詢，則相同節點的並行更新可能會產生 ConcurrentModificationException。這樣一來，可能會降低寫入效能。

如果您可以序列化可能彼此衝突的更新，則可以大幅降低此類衝突的可能性。例如，如果您可以確保指定節點的所有更新查詢都是在同一個執行緒上進行 (可能使用雜湊型指派)，則可以確保它們逐一執行，而不是同時執行。雖然對相鄰節點採取的範圍鎖定仍有可能導致 ConcurrentModificationException，但您可以消除對相同節點的並行更新。