2016-04-29 44 views
5

我在使用子上下文作爲NSPrivateQueueConcurrencyType的便箋時遇到了問題。使用NSPrivateQueueConcurrencyType子上下文與NSPrivateQueueConcurrencyType父上下文

我的核心數據堆棧看起來是這樣的: core data stack

視圖控制器使用的主要背景。 Worker Context用於從API導入數據。我正在使用mergeChangesFromContextDidSaveNotification合併主和工作環境之間的更改。如果我將「工作者子女」背景排除在外,事情似乎正常運作。

但是,我想在導入對象時使用工作人員子上下文作爲便箋。一些數據需要構建嵌套對象,並且如果在構建過程的某個地方出現錯誤,我想只是拋棄該背景。如果構建成功,我希望能夠保存工作者子上下文,讓它將更改推送到工作者上下文中,然後可以將更改保存併合併到主上下文中。

但是,當我嘗試在Worker Child Context中執行獲取請求來執行查找或創建操作時,即使它在Worker Child Context的performBlock內完成,我也得到了多線程斷言。

我不確定哪些代碼片段可以幫助回答這個問題,但我主要關心的是我的整體方法不起作用。有一個私人隊列上下文作爲另一個上下文的孩子是一個壞主意?

編輯:

我遇到的崩潰是當工人的孩子上下文將嘗試執行讀取請求做一個查找或創建操作。它沒有在謂詞中使用任何託管對象,並且其包裝在performBlockAndWait中。我得到的解釋是'NSInternalInconsistencyException',原因是:'語句仍然處於活動狀態'崩潰是間歇性的,但到目前爲止,它似乎只發生在嵌套工作者子上下文時。 (即我的圖中的工作人員子上下文將擁有自己的創建對象的子上下文)

導致崩潰的提取請求始終用於查找或創建操作,因此它試圖獲取具有唯一標識符的任何對象屬性與正在導入的對象的標識符匹配。所以謂詞總是像"identifier in ["1234", "abc", "etc" ]

正如我在評論中提到的,我最初使用PSC-> Private Context-> Main Context-> Private Worker Context設置。我遇到UI凍結,而工作者上下文在導入數據時提取並保存,所以我試圖重構此堆棧以釋放UI。

+0

你在做什麼導致多線程斷言的performBlock?這將提供關於發生了什麼問題的線索。 – Tim

回答

0

顯示您的提取及其謂詞將有助於確定發生了什麼。這聽起來像你正在跨越線程邊界訪問NSManagedObject,也許在謂詞中使用了一個?

順便說一句,如果您將您的工作人員移動到主隊列中,則無需處理使用通知。其他一切都會完全相同,但是您將需要更少的代碼來處理並減少線程問題的風險。

我最初有我的主要隊列下的工人。 PSC - >私人隊列 - >主隊列 - >私人工作人員。我正在重構我正在問的設置,因爲我的經驗是UI被阻塞,而工作人員上下文正在獲取/保存查找或創建導入。除了重構核心數據堆棧之外,是否還有另外一種方法可以優化性能?

您是否運行過儀器以確定該塊是來自兒童MOC?在任何情況下,我都聽說過這個問題,我發現它是其他問題(通常是UI相關),這是問題的實際來源。除非你用一個不好的謂詞取得對象的千行,否則你不應該感到一個獲取命中。即使這樣,謂詞也會被優化以解決問題。

至於保存,您可以A)增加保存頻率或B)設置私人MOC作爲磁盤寫入器。我更喜歡B,因此所有的保存都保證是異步的。

+0

我最初有我的主要隊列下的工人。 PSC - >私人隊列 - >主隊列 - >私人工作人員。 我正在重構我正在問的設置,因爲我遇到的問題是工作程序上下文正在提取/保存查找或創建導入時UI被阻塞。除了重構核心數據堆棧之外,是否還有另外一種方法可以優化性能? – alivingston

相關問題