Количество данных, хранящихся в сеансе - PullRequest
1 голос
/ 25 марта 2010

Какой метод мы должны использовать, чтобы объект httpsession не был сильно загружен данными.

Пример:

Запрос 1 ----> httpSession загружен с массивом из 50000 различных объектов. session.setAttribute ( "данные", ArrayList);

Запрос 2 ----> httpSession загружен с массивом из 40000 различных объектов. session.setAttribute ( "данные", ArrayList);

Предположим, что сервер сильно загружен несколькими сеансами и огромными данными в них. Скажем так из моего приведенного выше примера request1..1000 за раз. Что означает 1000 сессионных объектов с огромными данными.

Какой альтернативный способ решить вместо хранения их в сессии, как это?

Ответы [ 5 ]

3 голосов
/ 25 марта 2010

Некоторые идеи:

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

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

  3. Как уже упоминалось, используйте фреймворк для кэширования, такой как Ehcache. Это снижает потребность в программном коде в вашем приложении и позволяет совместно использовать кэширование во всех сеансах вместо дублирования данных. Конечно, если вы сохраняете только пользовательские данные в своем сеансе, обмен не принесет большой пользы. Подобная структура также позволяет вам настроить стратегию кэширования, например, чтобы она начала использовать базу данных при необходимости.

2 голосов
/ 25 марта 2010

Вместо этого поместите его в область приложения (если оно не зависит от пользователя) или замените его поиском / фильтрацией на основе базы данных (если это зависит от пользователя).

Я предполагаю, что данные уже хранятся в базе данных.Помещать его в область применения не имеет особого смысла.У вас всегда будут проблемы с памятью, когда код Java перемещает / копирует весь набор данных хранилища данных (например, СУБД) в памяти Java, а затем выполняет работу прямо в памяти Java с использованием кода Java.Это действительно ухудшится, когда вы даже сохраните / продублируете его в области видимости веб-приложения.

Наиболее эффективный подход к памяти - позволить базе данных выполнить задачу, для которой она придумана.Язык SQL предлагает вам в каждом предложении ORDER BY выполнить сортировку, предложении WHERE выполнить фильтрацию и (* в зависимости от поставщика БД) LIMIT/OFFSET предложения / функции / функции для возврата только подмножества записей на основе firstrow и rowcount или lastrow .Таким образом, вы получите только набор данных в памяти Java, который фактически должен отображаться.

Примеры необходимых запросов SQL можно найти в этом ответе Iразмещено раньше здесь.Надеюсь, это поможет.

1 голос
/ 25 марта 2010

Хранить только уникальные идентификаторы объектов, находящихся в общем пуле (память, дБ, плоские файлы)

0 голосов
/ 25 марта 2010

Я бы предложил вам попробовать один из двух вариантов:

  • Хранить пользовательские данные в вашей базе данных
  • Используйте систему кэширования, такую ​​как EhCache или memcached
0 голосов
/ 25 марта 2010

Вы можете установить атрибут в запросе или использовать формы, если вы используете данные в представлении. Если вам нужны данные, когда сеанс активен, поместите их в базу данных.

...