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

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

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

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

Мы не хотим использовать технологию кэширования, если в этом нет необходимости.

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

Любое руководство приветствуется.


spring session-state ehcache
person Mattd    schedule 15.07.2013    source источник
comment
Не могли бы вы пояснить, что вы имеете в виду под сервером приложений. Это полноценный сервер, например. JBoss, а может это тоже Tomcat?   -  person davidcyp    schedule 17.07.2013

Ответы (1)


arrow_upward
1
arrow_downward

Пара мыслей по этому поводу (отказ от ответственности: я работаю с terracotta / ehcache ... так что имейте это в виду ... но все же пытаюсь быть непредвзятым здесь):

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

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

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

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

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

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

person lanimall    schedule 17.07.2013