2014-04-28 25 views
1

我試圖模擬一個場景,有多個單獨的應用程序訪問我的數據庫。我這樣做的方式是創建10個不同的線程,這使得一些併發事務等。每個線程都有一個我的DbContext實例。EF 5.0 DbContext併發性的多個實例

問題是,DbContexts不知道其他實例中的更新。所以我的問題是,我如何確保我的DbContexts不包含不一致的數據?

+1

這不就像你的代碼在多臺機器上運行一樣嗎? – STLDeveloper

回答

1

如果使用除Serializable以外的任何隔離級別,則可能會導致某些級別的數據不一致。可串行化在性能方面相當昂貴,僅用於非常特殊的情況。

SERIALIZABLE 指定如下: 聲明不能讀取已修改但其他事務尚未提交的數據。 在當前事務完成之前,沒有其他事務可以修改當前事務讀取的數據。 其他事務不能插入具有鍵值的新行,這些鍵值落在當前事務中任何語句讀取的鍵範圍內,直到當前事務完成。 範圍鎖放置在與事務中執行的每個語句的搜索條件相匹配的鍵值範圍內。這會阻止其他事務更新或插入任何符合當前事務執行的任何語句的行。這意味着如果事務中的任何語句再次執行,它們將讀取相同的一組行。範圍鎖定一直持續到事務完成。這是隔離級別最嚴格的原因,因爲它鎖定了整個鍵的範圍並持有鎖直到事務完成。由於併發性較低,因此僅在必要時才使用此選項。此選項與在事務中的所有SELECT語句的所有表上設置HOLDLOCK的效果相同。

快照隔離還可以防止髒,不可重複和幻像讀取,但不會阻止線程1和線程2在重疊時間段內觀察不同的數據。

快照 指定任何聲明在一個事務中讀取的數據將是在事務開始時就存在的數據的事務上一致的版本。該交易只能識別交易開始前已提交的數據修改。在當前事務開始後由其他事務進行的數據修改對當前事務中執行的語句不可見。其效果就好像事務中的語句獲取了事務開始時所存在的已提交數據的快照。

這是一個相當廣泛的話題。一個好的起點是

http://technet.microsoft.com/en-us/library/ms189122(v=sql.105).aspx

交易指定定義哪一個事務必須從其它事務做出資源或數據修改被分離的程度的隔離級別。描述隔離級別的術語是允許併發副作用,如髒讀或幻讀。

1

問題是他們緩存他們調用的數據庫表。無論何時更新已經緩存的數據庫表,您都必須創建一個新的dbContext。

你也可以嘗試搞定緩存設置,以使它們更快地超時,所以更新的結果會更快地反映在其他dbContexts中(例如測試啓用和禁用延遲加載)。我誠實地從未嘗試過與他們玩太多;我一直只是做了一個新的dbContext,併爲我工作。