用戶實體DbContext在同時發生請求時被另一用戶破壞

我的項目使用Entity Framerwork 6.「n」類似數據庫有1個網站。用戶可以從數據庫切換到另一個數據庫。用戶實體DbContext在同時發生請求時被另一用戶破壞

//-> Unit of Work and repositories 
_currentContainer.RegisterType(typeof(ItrsEntities), new PerRequestLifetimeManager(), new InjectionConstructor()); 
_currentContainer.RegisterType(typeof(ItrsEntitiesWrapper), new InjectionConstructor(_currentContainer)); 

_currentContainer.RegisterType<IWorkshopRepository, WorkshopRepository>(); 
_currentContainer.RegisterType<IIndexRepository, IndexRepository>();

當兩個用戶同時點擊時，會出現此問題。第二位用戶從第一位點擊用戶處「破壞」DbContext。

它是由表現：

的ObjectContext的實例已經設置，不能再用於需要連接的操作。
的操作，因爲的DbContext已經設置無法完成。
...隨機誤差

問題的其他奇怪的表現形式很多的：

第一個用戶（從另一個數據庫中的數據）獲得第二個用戶的數據。這就像第二個用戶替換第一個用戶的DbContext ...

ItrsEntities是DbContext。爲了解釋我的用戶是什麼，在測試期間，我使用了兩臺不同的電腦和兩個不同的Windows帳戶。我不在本地，我已經在服務器上部署了該網站。（在本地沒有問題，因爲我一個人）。

我正在使用PerRequestLifetimeManager。我認爲這是一個實施問題，但沒辦法找到問題所在。在此先感謝，

來源

2015-11-20 Nemesis

聽起來像你有一個範圍界定問題。每個用戶請求（或至少每個用戶會話）應限制服務器上的DbContexts。這聽起來像是每當你創建/註冊DbContext時，它都沒有被正確地區分 – Vlad274

你忘了告訴我們DbContext是什麼類的......我猜ItrsEntities有點不錯。 –

另外，這裏的'用戶'是什麼？你如何測試？ –

聽起來好像你在應用程序的生命周圍保留了一個Context，這是一個非常嚴重的反模式。它會導致各種錯誤，就像您在代碼中看到的那樣，特別是涉及多個線程時。建議的模式是爲每個「邏輯工作單元」創建一個新的上下文，最好由一個using塊包圍。

上下文構造起來相當便宜，但是由於緩存的原因，它們傾向於收集「cruft」時間更長的時間，這會嚴重減慢應用程序的速度。通過保持Context的生命週期較短，您可以將這種影響降至最低，並將邏輯操作彼此隔離開來，從而使調試變得更容易。

來源

2015-11-20 19:49:21

在那裏有一個PerRequestLifetimeManager，我們不能分辨它是否被正確使用。 –

用戶實體DbContext在同時發生請求時被另一用戶破壞

回答

相關問題