出于性能原因，我必须在内存中缓存对象层次结构，这反映了一个包含列（ObjectID、ParentObjectID、Timestamp）的简单数据库表并查看 CurrentObjectHierarchy。我查询 CurrentObjectHierarchy 并使用哈希表来缓存每个对象的当前父对象，以便在给定任何对象 ID 的情况下快速查找父对象 ID。查询数据库表和构建缓存平均需要 77 毫秒的操作，理想情况下，只有在调用我的数据库 API 中的一个方法会改变层次结构（添加/删除/重新设置对象）时才会发生这种刷新。
如果必须由多个 ASP.NET Web 应用程序访问，可能在不同的应用程序池中运行，那么这种缓存的最佳位置在哪里？
最初，我将缓存存储在不同 Web 应用程序共享的 C# dll 中的静态变量中。当然，问题在于，虽然静态变量可以跨线程访问，但它们不能跨进程访问，当涉及多个 Web 应用程序时（可能在单独的应用程序池中运行），这是一个问题。结果……在一个应用程序中对对象层次缓存的同步、线程安全的修改不会反映在其他应用程序中，即使它们使用相同的代码库。
所以我需要一个更全局的位置来存放这个缓存。我不能使用静态变量（正如我刚刚解释的）、会话状态（基本上是每个用户的存储）和应用程序状态（需要跨应用程序访问）。
我一直在考虑的潜在地方是：
- IIS 本身内的某种全局对象存储，可从任何应用程序池中的任何应用程序中的任何线程访问（如果存在这样的地方。是吗？）
- 管理独占缓存的单独的自定义 Web 服务。
现在，我认为最好的解决方案是 SQL CLR 集成，因为：
- 我可以使用静态变量保持我当前的设计
- 这是一个已经存在的单独服务，所以我不必编写自定义服务
- 它将在单个进程（SQL Server）中运行，因此现有的基于锁的同步可以正常工作
- 缓存将尽可能接近它所代表的数据结构！
我将在 SQL CLR DLL 中嵌入层次遍历方法，这样我就可以在通常进行常规方法调用的地方进行单个 SQL 调用。这一切都取决于在单个进程中运行的 SQL Server 以及将 CLR 加载到该进程中，我认为是这种情况。你觉得这怎么样？你能看出我可能遗漏的这个想法有什么明显的错误吗？这不是一个很棒的主意吗？
编辑：仔细观察后，似乎不同的 ASP.NET 应用程序实际上运行在同一个进程中，但被 AppDomains 隔离。如果我能找到一种跨 AppDomain 共享和同步数据的方法，那将非常有用。我现在正在阅读有关 .NET Remoting 的信息。