cdtyjv- может стать узким местом при наращивании нагрузки
Это спорный вопрос. Обычно узким местом становится репликаций HTTP сессии в JEE на кластере.
В случае хранения сессии в БД, репликация не нужна. Масштабируемость должна быть лучше.

cdtyjvЭто как? В куках хранят идентификатор сессии, а саму сессия хранят на сервере.
Не уверен, что именно пытается сказать Petro123. Но есть ещё и такой способ оптимизации сессии, как вынос состояния на клиента.
Т.е. данные сессии хранятся в куках и на странице в подписаном виде. Такой подход может серьезно снизить нагрузку с сервера за счет незначительного прироста трафика.

BlazkowiczТакой подход может серьезно снизить нагрузку с сервера за счет незначительного прироста трафика.
А если реализовать полноценное RIA, то даже и прироста трафика не будет. Ведь нет смысла всё состояние гонять на сервер.

osonПодскажите пожалуйста, какие есть плюсы и минусы хранить состояние сесии для REST сервиса в БД?
Сессия не имеет отношение к HTTP и REST. Поэтому упоминание REST тут лишнее.
Если же говорить о RIA, где сервер реализован в виде REST сервиса, то возникает вопрос. Почему сессия не живет на клиенте? Зачем она серверу?

osonМожно сказать, что сессия поддерживается на стороне клиента. Клиент получает auth_key при логине и потом при каждом следующем запросе должен отсылать его. А на стороне сервера по этому auth_key каждый раз находится его session object, в котором записано, что этот клиент уже авторизовался, что он имеет определенные права доступа, и если он вызывает сервис, к которому доступа не имеет, то получает сообщение о нехватке прав.
Это всё? В такой ситуации никаких особых бенефитов при переносе сессии в базу не будет. Даже если репликации сессии нет и нода упадёт, то клиенту просто нужно перелогинится.


osonЧто тут не так? Какой RIA я не знаю. Я выдаю только REST интерфейс, а что с ним делает разработчик интерфейса на разных клиентах, это его уже дело.
Вы знаете своё ТЗ, а мы нет. Поэтому мы отвечаем на общий вопрос устредненной ситуации и не стоит удивлятся тому что ответ может не подходить вашему конкретному случаю.

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

Йуный джавистЪВроде бы канонический рест подход состоит в том, чтобы информация о правах доступа каждый раз доставалась из базы,
Канонический REST никакого отношения к базе не имеет.

Йуный джавистЪсоответственно на сервере ничего хранить не надо.
Угу. Только потом появится кеш в памяти, для опимизации доступа к БД, который в результате будет работать совершенно идентично HTTP Session.