Это одна часть целого ряда проектных решений, касающихся того, где нам нужно хранить информацию о состоянии, когда несколько компьютеров задействованы в системе.
Когда вы говорите «сессия», я подозреваю, что вы имеете в виду HttpSessionКонтейнеры сервлетов будут управлять для вас.На самом деле вполне вероятно, что HttpSession поддерживается с помощью cookie: cookie просто содержит какой-то ключ к таблице сеансов.
Такая схема передачи некоторого уменьшенного объема данных обратно в браузер и отслеживания основных данных сервером также довольно распространена.Иногда люди используют все три: cookie для, скажем, небольших вещей, HttpSession в качестве удобного кэша и базу данных для вещей, которые им действительно нужны.
Есть много факторов, которые нужно учитывать, вот несколько:
- Сколько данных целесообразно отправлять в куки, слишком много вещей будет работать медленно.
- Насколько это безопасно?Серверы часто собирают намного больше данных, чем пользователь ввел в этом сеансе, насколько мы уверены, что что-то чувствительное не может быть взломано или прочитано, если мы отправим его обратно в браузер в виде файла cookie?
- Насколько надежны нашивыбор механизма сессии?Потерять браузер, потерять ту 5к бронь, которую мы собирались купить?Потерять HttpSession на сервере?Возможно, тот же результат?(Некоторые серверы приложений имеют репликацию сеансов, но это накладные расходы).
Лично я нахожу, что обычно HttpSession API настолько удобен, что я никогда не решаю использовать куки.Мое эмпирическое правило гласит: «если его легко создать заново, сохраните его в HttpSession, в противном случае убедитесь, что оно сохраняется в базе данных, при необходимости создайте базу данных специально для управления состоянием (и не забывайте о ведении этой базы данных).
Примеры воссоздаваемых вещей: Предметы, извлеченные из базы данных (мы всегда можем получить их снова), вещи, которые пользователь не будет возражать против повторного ввода (скажем, несколько критериев поиска).на 17 странице заполнена страховая заявка.