以下是我們所處的情況。如何讓我的appDomain更長壽？
我們將我們的程序集（純粹爲DLL）分發給我們的客戶（我們無法控制其環境）。
他們打電話給我們，通過傳遞一個項目的ID列表，我們搜索我們龐大的數據庫，並以最高的價格返回項目。由於我們有我們的SLA（30毫秒）見面，我們正在緩存我們的項目（使用Microsoft MemoryCache）我們正在緩存大約一百萬個項目。
這裏的問題是，它只在我們的客戶端應用程序生命週期中緩存。當進程退出時，所有緩存的項目也是如此。
有沒有一種方法可以讓我的memorycache壽命更長，以便後續進程可以重用緩存項目？
我已經考慮過有一個窗口服務，並允許所有這些不同的進程與同一個盒子上的一個進行通信，但是當涉及到部署時，這會造成巨大的混亂。
我們使用AppFabric作爲我們的分佈式緩存，但實現我們的SLA的唯一方法是使用memorycache。
任何幫助將不勝感激。謝謝
我不明白的方式，以確保您的AppDomain生活不再 - 因爲所有調用程序集所要做的就是卸載的AppDomain ...
辦法之一 - 雖然凌亂too-實施某種「持續的MemoryCache」 ......來實現性能你可以/會用ConcurrentDictionary堅持一個MemoryMappedFile ...
另一種選擇是使用本地數據庫 - 甚至可能是Sqlite和實施緩存接口在內存中，使得所有的寫入/更新/刪除都是「直通式」，而讀取是純粹的RAM訪問...
另一個選擇可能是包含一個EXE（例如嵌入式資源），並從DLL內部啓動EXE（如果未運行）EXE提供MemoryCache，通信可以通過IPC（例如共享記憶...）。由於EXE是一個獨立的進程，它將保持活着，即使在卸載你的AppDomain後......這個問題更多的是客戶是否喜歡和/或允許它...
我真的很喜歡Windows服務方法，儘管我同意這可能是一個部署混亂...
基本問題似乎是你沒有控制運行時主機 - 這是什麼控制壽命（並因此控制緩存）。
我會研究創建某種（輕量級？）主機 - 也許一個.exe或服務。
您的DLL的大部分將掛起新的主機，但你仍然可以部署一個「外觀」DLL，反過來調用你的主要解決方案（綁定到你的主機）。是的，您可以讓外部客戶端直接呼叫您的新主機，但這意味着需要更改/重新配置這些外部呼叫者，因爲將原始DLL/API保留在原位可以將外部呼叫者與內部更改隔離。
這將（我假設）意味着完全拆卸和重新構造您的解決方案，尤其是無論外部調用者當前打的什麼DLL，因爲它不會處理請求本身，而只是將請求傳遞給您的新主機。
性能
進程間的通信是不是將它保持在一個進程中更昂貴的 - 我不知道如何在方法上的變化會影響你的表現，並擊中了SLA的能力。
特別是，啓動主機的新實例將導致性能下降。
您是指您的客戶的客戶端應用程序或查找服務？ – Kev
對於我的客戶的客戶端應用程序。 – kepung
有趣的問題:) –