Я должен кешировать иерархию объектов в памяти из соображений производительности, которая отражает простую таблицу базы данных со столбцами (ObjectID, ParentObjectID, Timestamp) и просмотр CurrentObjectHierarchy. Я запрашиваю CurrentObjectHierarchy и использую хеш-таблицу для кэширования текущих родителей каждого объекта для быстрого поиска идентификатора родительского объекта по заданному идентификатору объекта. Запрос к таблице базы данных и построение кеша - это в среднем операция 77 мс, и в идеале это обновление происходит только при вызове метода в моем API базы данных, который изменит иерархию (добавление / удаление / переопределение объекта).
Где лучшее место для такого кэша, если к нему должны обращаться несколько веб-приложений ASP.NET, возможно, работающих в разных пулах приложений?
Изначально я хранил кеш в статической переменной в C # dll, совместно используемой различными веб-приложениями. Проблема, конечно, заключается в том, что, хотя к статическим переменным можно обращаться через потоки, они не могут быть доступны через процессы, что является проблемой, когда задействовано несколько веб-приложений (возможно, работающих в отдельных пулах приложений). В результате ... синхронизированные, поточно-ориентированные изменения в кэше иерархии объектов в одном приложении не отражаются в других приложениях, даже если они используют одну и ту же кодовую базу.
Так что мне нужно более глобальное расположение для этого кэша. Я не могу использовать статические переменные (как я только что объяснил), состояние сеанса (которое в основном является хранилищем для каждого пользователя) и состояние приложения (должно быть доступно через приложения).
Потенциальные места, которые я рассматривал:
- Какой-то тип глобального хранилища объектов в самом IIS, доступный из любого потока в любом приложении в любом пуле приложений (если такое место существует. Есть ли?)
- Отдельный настраиваемый веб-сервис, управляющий эксклюзивным кешем.
Сейчас я думаю, что ЛУЧШЕЕ решение - это интеграция SQL CLR , потому что:
- Я могу сохранить свой текущий дизайн, используя статические переменные
- Это отдельный сервис, который уже существует, поэтому мне не нужно писать собственный
- Он будет работать в одном процессе (SQL Server), поэтому существующая синхронизация на основе блокировки будет работать нормально
- Кэш будет устанавливаться как можно ближе к структурам данных, которые он представляет!
Я бы встроил методы обхода иерархии в DLL-библиотеку SQL CLR, чтобы можно было сделать один вызов SQL, где я обычно выполняю обычный вызов метода. Все это зависит от SQL Server, запущенного в одном процессе, и от загрузки CLR в этот процесс, что, как мне кажется, имеет место. Что ты думаешь об этом? Можете ли вы увидеть что-то явно не так с этой идеей, которую я могу пропустить? Разве это не потрясающая идея?
EDIT:
После более тщательного изучения кажется, что разные приложения ASP.NET на самом деле выполняются в одном и том же процессе, но изолируются доменами приложений. Если бы я мог найти способ обмениваться данными и синхронизировать их между доменами приложений, это было бы очень полезно. Я сейчас читаю о .NET Remoting.