我們有一個傳統的多租戶（每個租戶都有它自己的數據庫，但他們都有着相同的代碼和虛擬機）系統建立在asp.net MVC 4.由於一些性能問題，我們開始逐漸改變它。我們做統一DI行爲不端的異步操作
的一件事是使用統一DI /國際奧委會工作。到目前爲止，在容器上註冊的唯一東西是使用PerRequestLifetimeManager的EF DbContext。到目前爲止，沒有其他項目被註冊。每當一個服務或控制器被instatiated，
我們做的另一件事是做一些操作異步......我們打算讓它們異步，但我們會一個接一個。
我們的內部測試很成功，我們已經部署到生產環境。
真實流量的幾個小時後，我們開始注意到一些問題......當系統報告了一堆東西，爲此，根本原因是莫名其妙的誤差修改：「ID不存在」。對於一個特定的租戶來說，這些差距很大（每個租戶每天發生的次數少於10次 - 平均每個租戶每天使用3千次的業務量），但是在總數上，這變得非常重要。手動捕獲和執行總是返回預期的結果。
搞錯了，在某一個點一個開發已經登錄EF用的是完整的連接字符串，併爲我們驚訝的是，錯誤的數據庫被擊中！客戶端A確實試圖從客戶端B數據庫讀取一些內容！
尋找所有的地方，我們通過TransactionScopeAsyncFlowOption.Enabled和<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />但錯誤仍然發生去......
我們計算過，有故障的根源在這裏2個可能的位置：要麼我們搞砸了的時候當我們呼叫Resolve時，創建DbContext或unity將放棄錯誤的實例。
因爲創建邏輯根本沒有改變，而且之前沒有發生過，所以我們認爲Unity在這裏有問題。
重要的是要注意到這一點很重要，因爲據我們所知，使用DI沒有同步操作（系統的約95％，現在，5％是異步OPS）過這樣的問題。
任何人都知道可能會發生什麼？
詳細信息：
- 在Azure App Services上支持，框架版本爲4.6 - 水平縮放。但是，這種情況即使只有1個實例可以處理負載
這個問題的方式過於寬泛。你將不得不想出一個[最小，完整和可驗證的例子]（https://stackoverflow.com/help/mcve）。沒有這樣的例子，我們在這裏無能爲力。 – Steven
團結不再被維護（現在已經好幾年了），並且已經落後於其他DI容器的功能。那麼爲什麼人們仍然期望得到它的支持？坦率地說，我厭倦了在StackOverflow上看到這個已停用的容器的問題，要求通過切換到現代的方法來避免問題的答案。 – NightOwl888
@ NightOwl888我不知道！這是一個非常有用的信息！分享很多！我有點懷疑，但無法找到一個直接的帖子或類似的東西...你在哪裏讀到的？ – Leonardo