HttpContext 的服務器端等價物？

Question

我有一個 web 應用程序，它當前使用當前的 HttpContext 來存儲 LINQ 數據上下文。 根據Rick Strahl 的博客，基於每個用戶的當前請求的上下文是持久的：

string ocKey = "ocm_" + HttpContext.Current.GetHashCode().ToString("x")  
Thread.CurrentContext.ContextID.ToString();

if (!HttpContext.Current.Items.Contains(ocKey))
{
    // Get new Data Context and store it in the HTTP Context
}

但是，我有一些從 global.asax 文件執行的腳本，它們沒有HttpContext。 HttpContext.Current 是 NULL ，因為服務器是發出“請求”的那個。

是否有等效的 object 可用於存儲數據上下文？ 所以我不必擔心重新創建它和附加/分離對象？ 我只想在我的流程的整個生命周期中保留上下文。

更新：

我目前正在嘗試在我的 DAL 助手 class 中使用 static 變量。 在第一次調用 class 中的一個方法時，DataContext 被實例化，並存儲在 static 變量中。 在我的過程結束時，我調用另一個在 DataContext 上調用 Dispose 的方法，並將 static 變量設置為 NULL。

Answer 1

你能不能只為這些腳本使用 static 變量？ 這將具有與AppDomain相同的生命周期。 您可能應該仔細考慮任何並發問題，但這聽起來像是保持價值的最簡單方法。

（我剛剛檢查過，雖然HttpApplication的一個實例可用於服務多個請求，但每個實例一次只服務一個請求 - 這表明為並發請求處理創建了多個實例。我尚未對此進行驗證，但聽起來確實將其保存在實例變量中並不安全。）

編輯：喬希的回答表明你希望這是每個線程。 這對我來說聽起來有點奇怪，因為除非您發生了很多這樣的事件，否則您很可能只會看到它們在不同的線程上執行，從而使整個共享業務毫無意義。 如果你真的想要那種東西，我建議只在HttpApplication派生的 class 中使用一個實例變量 - 正是上面段落中描述的原因:)

Answer 2

為什么不使用當前的 HttpContext？ global.asax 文件中的腳本都是請求進入服務器的結果，因此應該有一個與該請求相關聯的上下文，您可以獲取該上下文。

我不明白需要根據哈希碼或線程生成密鑰。 每個傳入的請求都會有一個單獨的 HttpContext 實例，並且該實例將特定於處理請求的線程。 因此，當它基於 HttpContext 的實例和線程時，密鑰幾乎毫無價值。

另外，完成后如何處理 DataContext？ 它實現 IDisposable 是有原因的，所以我建議不要使用這樣的共享實例。

---

更新

在評論中，它表明有一個正在運行的計時器正在執行腳本。 我建議不要設置計時器，而是設置一個計划任務，該任務將調用網站上的 Web 服務或預定頁面來執行該任務。 然后，您將始終有一個 HttpContext 可以使用。

Answer 3

HttpContext.Current 是一個 static 方法，只要代碼在請求的上下文中執行，就應該可以在任何地方使用。

在您的情況下，您沒有在請求的上下文中執行，您可以查看使用 Application.Cache 但我會警告不要保持 DataContext 打開。 我對實體的 linq 不是很熟悉，所以我可能是錯的，但通常緩存與數據庫相關的項目（如連接）是不好的。

我還建議您考慮將邏輯移出 global.asax 並移至 windows 服務。 這將使您可以更好地控制這些任務，例如，您可以將它們關閉 web 站點的單獨。

編輯

正如 JS 指出的那樣，您可以使用 static 變量。 您還可以定義一個標有 ThreadLocal 屬性的實例變量。 這將為每個線程提供自己的變量副本，並且可以消除爭用。 因為您希望每個線程都有自己的副本。

Answer 4

是否有理由需要以與其他 DataContexts 相同的方式處理這些？ 在我看來，如果僅在事件處理例程中需要上下文，則不需要保留它。 特別是如果它在 Application_Start 中（根據您的評論），我不會費心在任何地方緩存它——只需在本地使用它並根據需要將它傳遞給其他方法。

Answer 5

創建定時器時，將 DataContext 設置為 state 參數。 根據您在評論中發布的信息，在我看來，您的 DataContext 與計時器的關系比其他任何東西都多。

還要避免對不同的計時器使用相同的 DataContext，因為您最終會得到來自不同計時器的混合修改。 還要確保您的相同計時器邏輯沒有運行兩次，因為它會導致相同的時間，即時間太短而無法控制。