Должен ли я использовать Spring Session Scoped beans или кеш, например ehcache?

Question

У нас есть приложение, которое должно поддерживать состояние, так что некоторые объекты, содержащие данные (потенциально много), могут быть опрошены клиентом (браузером) в интерактивном взаимодействии. Было бы неэффективно перезагружать данные с каждым запросом.

Мы используем Spring и сессионные компоненты для поддержки некоторых контролируемых сеансом данных. Однако эти новые бобы будут больше.

Будет ли это подходящим использованием фаз с сеансовой обработкой или будет лучше подходит кэш (ehcache)?

Мы не хотим тянуть технологию кеширования, если мы действительно не должны.

Другим фактором является то, что приложение необходимо будет развертывать в кластере. В этом случае результирующие сеансовые бобы реплицируются репликацией сеанса сервера приложений или, было бы более эффективно использовать ehcache (который, как я полагаю, может быть распространен в кластере)?

Любое руководство оценено.

Answer 1

Пара мыслей об этом (оговорке: Я работаю на терракота/EHCache ... так что имейте это в виду ..., но все еще пытается быть беспристрастным здесь):

1 - Есть ли какие-либо избыточные данные в каждой из сессий? Все, что можно было бы разделить между сессиями? Если да, +1 для ehcache для хранения общих вещей (потому что ehcache оптимизирован для интенсивного параллелизма)

2 - Насколько велики ваши объекты сеанса? И сколько одновременных пользователей вы ожидаете на постоянной основе? (другими словами, сколько памяти вам нужно посвятить сеансовому хранилищу на вашем сервере приложений?)

Если размер сессии невелик и может отлично вписываться в вашу кучу без проблем с GC, то с использованием сеанса должно быть прекрасным решением.

Но чем больше он будет, тем больше ваша куча java должна быть ... и тем больше вам придется использовать трюки voodoo, чтобы держать сборки мусора и время паузы gc под контролем. Используя ehcache, вы можете централизованно хранить некоторые объекты, к которым могут иметь доступ несколько сеансов ... следовательно, консолидировать объем памяти (то же самое, что и 1) Кроме того, с использованием корпоративного расширения для ehcache (BigMemory = http://terracotta.org/products/bigmemory) вы можете обойти кучу ограничения и хранить данные вне кучи (столько, сколько необходимо - 10, 100 и более GB). При этом размер объектов, которые должны быть в памяти, становится неактуальным (если вы, конечно же, можете добавить RAM на свой сервер)

3 - Для репликации сеансов серверы приложений, такие как поддержка JBOSS, Weblogic, Websphere Это. Опять же, это вопрос размера сеанса снова (сколько данных нужно будет реплицировать по кабелю). Если объекты сеанса большие, и у вас их много, в вашем кластере будет много сетевого трафика ... может или не получится. Наличие основных объектов в распределенном EhCache-слое, оптимизированном для хранения данных, при сохранении минимальной сессии (т. Е. Информации входа/аутентификации), несомненно, улучшит этот механизм репликации сеанса.

Надеюсь, что это поможет.