Разработка идей о кеше контекста уровня приложения (аналогично сеансу / контексту приложения в сети)

Question

У нас есть веб-приложение, которое включает создание некоторых тяжелых служебных объектов (с точки зрения производительности памяти). Его может использоваться на любом уровне приложения . Эти служебные объекты являются специфическими для пользователя. Поэтому в идеале должно происходить создание этих объектов, когда пользователь входит в систему, кэширование их «где-то» и их повторное использование там, где это необходимо.

доступные опции сейчас - это Сессия, Приложение. Но они доступны не для всех уровней. Один из способов - передать их следующим уровням. Но это будет нарушать подход разделения интересов , и другие уровни должны будут знать о веб-уровне.

Другой подход - использовать статический служебный класс для кэширования этих объектов. Что-то вроде

MyUtilObject myObject = MyUtilCache.getMyUtilObject(userName);

Внутренне, подкрепленный чем-то вроде HashMap (и, возможно, мягкой ссылкой). Эти объекты будут очищены при выходе пользователя из системы или истечении сеанса.

Вот что мы используем

JBoss, Struts1.2, Spring. Все ярусы включены на одном компьютере (за один раз).

Пожалуйста, поделитесь своими мыслями / подходами по этому поводу.

Answer 1

Все, что вам нужно, это интерфейс, общий для всех уровней.Реализация может быть поддержана Session и внедрена везде, где это требуется.

Answer 2

Почему бы не сериализовать / десериализовать объекты по мере необходимости. Когда в этот момент требуются объекты, десериализуйте их и при закрытии сеанса снова сериализуйте их

Answer 3

создание тяжелых объектов Utility

Объясните подробно, когда пользователь входит в систему, какие тяжелые объекты хранятся в течение определенного периода времени?

Это всегдахорошо иметь меньший объем данных HttpSession.Typical сеанс веб-приложения длится для секунд или минут для пользователя.В основном он должен содержать авторизацию, пользовательские настройки, информацию о подключении и состояния. Он не должен содержать данные, которые полезны с текущей страницы на следующую.Конечно, вы можете хранить слишком много данных, поскольку кучи сеансов - это предел.Но могут быть условия гонки, если вы храните в течение длительного времени.Если для этого запроса требуются данные, сохраните их в HttpRequest.В противном случае у вас есть кэши 2-го уровня, такие как EHCACHE , * MEMCACHE * или TerraCotta , применяйте политики, такие как до окончания сеанса, сделайте этот кеш доступным для всехстраницы.Также между каждой страницей передается уникальный идентификатор, который определяет информацию о кэше.

Другой подход заключается в использовании статического служебного класса для кэширования этих объектов.

Статический класс является общим длявсе пользователи.Как вы можете иметь статический класс, специфичный для пользователя.