在繼承實體上運行PLINQ拋出AccessViolationException

在測試與EF與SQL-Compact 3.5數據庫接口的應用程序時，我遇到了瓶頸。在繼承實體上運行PLINQ拋出AccessViolationException

通常，當我遇到像這樣的瓶頸時，我重新加工linq查詢以減少linq查詢的數量，因爲在數千個條目填充的數據庫上重複運行相同的linq查詢十幾次創建了一些的開銷。然後，我使用plinq來加快實例化時間。

這樣做一直工作得很好，直到我試圖用ShapeEntities表來做到這一點。

ShapeEntity是一個抽象實體，它用作其他實體的基類，這些實體與其他實體幾乎相同。我不能用AsParallel（）方法運行這個。

HashSet<Guid> keys ... 

var x = 
    from shape in model.ShapeEntities.AsParallel() 
    where keys.Contains(shape.ImageKey) 
    select shape; 

List<ShapeEntity> shapes = new List<ShapeEntity>(x);

如果我從上面的代碼中刪除了AsParallel（），那麼當我們把它放到列表中時，查詢大約需要1.4秒的時間來執行。使用AsParallel（）方法，大約40秒後我得到一個AccessViolationException。它永遠不會過去實例化。

有沒有人有關於如何加快這一點的任何想法？我無法完成ImageEntity.ShapeEntities，因爲它每個ImageEntity會變成1.2秒。

來源

2012-02-11 Francisco Chavez

我不認爲EF上下文是線程安全的。我很確定這意味着你不能在PLINQ中使用它們。 – Gabe 2012-02-11 01:28:57

實體框架上下文不是線程安全的。 From MSDN

ObjectContext類不是線程安全的。在多線程的情況下，無法確保ObjectContext中的對象的數據完整性。

如果您正在使用NoTrackingMergeOption

model.ShapeEntitie.MergeOption = MergeOption.NoTracking;

否則執行一些分頁機制檢索這些實體爲只讀的目的，您可以節省幾毫秒。

來源

2012-02-11 01:28:38 Eranga

在這種情況下，分頁機制是什麼意思？ – Gabe 2012-02-11 01:33:12

我試過NoTracking選項，但它不想混合和匹配MergeOptions。這些表是隻讀的，但其中一些表可以在任何時候編輯。 – 2012-02-11 01:53:47

在繼承實體上運行PLINQ拋出AccessViolationException

回答

相關問題