Какое ключевое преимущество (в отношении масштабируемости) механизма cookie + кеша в Play 2.0 по сравнению с Java EE HttpSession?

Question

Я понимаю, что нам не нравится поддерживать состояние сеанса на сервере по причинам масштабируемости в целом, но я просто не понимаю, почему подход, принятый в Play 2.0, считается лучше, чем старая школа HttpSession.

Основное различие, которое я вижу, состоит в том, что реализация HttpSession обеспечивается контейнером, и, следовательно, от него зависят возможности масштабирования с помощью HttpSession.

Answer 1

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

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

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

Answer 2

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

Напротив;когда ваше приложение не поддерживает никакого реального состояния сеанса в любой точке (как должно делать ваше приложение Play), его очень легко масштабировать по горизонтали: просто добавьте больше узлов, которые запускают приложение, и убедитесь, что внешний HTTP-сервер знает о новых узлах.Нет причудливых алгоритмов и «корпоративных платформ» для репликации и поддержки сеансов на всех узлах.

Answer 3

Нет, на самом деле все немного сложнее.Play на самом деле использует архитектуру приложения без состояния .Это означает, что вы не храните никаких данных в сеансе.Ничто, кроме учетных данных не может быть сохранено.

Первое правило : хранилище сеансов депортируется в базу данных.Вместо того, чтобы извлекать данные из сеанса, получите их из базы данных.Масштабируемость для баз данных намного проще, чем для приложений JVM.

Второе правило : Ничего не сохраняется, кроме учетных данных.Это означает, что вам придется передавать информацию в противном случае для состояний разговорного канала.Есть два основных способа сделать это.Использование скрытых полей, что, на мой взгляд, не лучший способ.Во-вторых, используйте абсолютные URL.Создайте URL , содержащий идентификаторы, поиски и прочее.