避免多個NSManagedObjectContexts之間的無限遞歸同步

我有兩個託管的上下文設置（在iPhone應用程序上）。我用於大多數查詢的主要上下文以及用於我想要在後臺發生的長時間運行操作的背景上下文。

我已經針對每個託管對象上下文爲NSManagedObjectContextDidSaveNotification設置了通知。爲了響應通知，我調用mergeChangesFromContextDidSaveNotification來同步。這也是一個要求，任何時候在主要環境中發生變化時，我都需要在後臺環境中運行一些工作，因爲狀態現在已經改變了。

這工作正常，只要寫在上下文中的一個。在這種情況下，寫在主要的上下文中。但是，如果我在背景上下文中編寫，則會導致無限循環。保存在背景上下文觸發通知主要上下文，然後合併更改並觸發自己的通知，由背景上下文獲取。這觸發後臺上下文執行其後臺作業，而後者（如果他們寫入任何內容）會再次啓動該循環。

看來，這是錯誤的設置，或者我需要一種方法來解耦「更改通知中的任何時候在主要上下文中發生變化時啓動處理後臺作業」，或者我需要使背景上下文讀取-只要。

想法？與典型的「第二上下文是導入」場景不同的是，我相信我需要/希望我的背景上下文關於主要上下文保持最新，以便從我的背景中獲得正確的結果工作。

來源

2010-07-28 Duane Fields

我不知道你的具體應用程序，但是在一般的CS中，如果你有一個循環依賴，你必須檢測/中斷，你可以添加狀態（在包含上下文的範圍內的附加變量），所以你'重新實施「標記和掃描」。 – 2010-07-28 23:39:37

聽起來像一個設計問題。雖然你可以繞過它，但你應該考慮避免擁有「永久」的背景環境。我通常建議每個操作（NSOperations非常適合）爲每個操作建立一個上下文，然後在完成一項工作時將其丟棄。這樣可以避免需要保持多個上下文同步，因爲您只需更新主要上下文。

爲什麼你認爲你需要一個永久的背景環境？如果原因是性能，你分析過它嗎？

來源

2010-07-28 23:36:07

好點 - 我在腦海裏想創造一個新的背景是一些「昂貴」的東西，但沒有，我沒有測量它。我想很容易爭辯說，如果背景背景的原因是因爲我需要做一些「很長一段時間」的事情，那麼很容易證明在那段時間內分攤額外的啓動開銷是合理的。那麼在你的經驗中，你是在暗示創建一個新環境的情況相對便宜？ – 2010-07-29 14:10:39

創建一個新的上下文是很昂貴的，但是它試圖保持兩個上下文同步並保持後臺線程運行（*因爲第二個上下文應該在該後臺線程上創建**，而不是傳遞給它）。所以，是的，創造是昂貴的，但遠遠低於試圖保持活着「以防萬一」。 – 2010-07-29 16:42:51

您可以爲包含您收到的所有NSNotifications的上下文創建一個NSSet。每當你找到另一個時，只需在撥打mergeChangesFromContextDidSaveNotification之前對其進行檢查。來想想看，存儲最後一個爲上下文應該是足夠的...

來源

2010-07-28 22:12:22

避免多個NSManagedObjectContexts之間的無限遞歸同步

回答

相關問題