Почему переменная сеанса должна быть сериализуемой? - PullRequest
0 голосов
/ 27 января 2019

При попытке сохранить переменную списка пользовательских объектов
session.setAttribute жалуется, что переменная не сериализуема.

Ответы [ 3 ]

0 голосов
/ 27 января 2019

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

Таким образом, ваши объекты сеанса должны быть Serializable.

0 голосов
/ 27 января 2019

Как объяснили другие ответы, цель требования, чтобы переменные сеанса были сериализуемыми, состояла в том, чтобы это позволяло инфраструктуре контейнера использовать сериализацию объектов для:

  • перенос сеансов между экземплярами сервера в реализации распределенной веб-службы
  • сохранять сеансы через перезапуски сервера или для экономии памяти.

Но интересно то, что спецификация Servlet 3.0 на самом деле этого не требует. Вместо этого он говорит:

7.7.2 Распределенные среды

В приложении, помеченном как распространяемое, все запросы, которые часть сеанса должна обрабатываться одной JVM за раз. Контейнер должен иметь возможность обрабатывать все объекты, помещенные в экземпляры HttpSession класс с использованием методов setAttribute или putValue соответственно. Следующие ограничения накладываются для удовлетворения этих Условия:

  • Контейнер должен принимать объекты, которые реализуют интерфейс Serializable.

  • Контейнер может выбрать поддержку хранения других обозначенных объектов в HttpSession, таких как ссылки на Enterprise Компоненты и транзакции JavaBeans.

  • Миграция сессий будет осуществляться с помощью специальных контейнеров. Контейнер распределенного сервлета должен выдать IllegalArgumentException для объектов, где контейнер не может поддержка механизма, необходимого для переноса хранения сессии их. Контейнер распределенного сервлета должен поддерживать механизм необходимо для переноса объектов, которые реализуют Serializable.

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

Если мы проанализируем это внимательно, то это говорит о том, что:

  • A распределенный контейнер должен поддерживать сериализацию объектов как один из способов переноса объектов в сеансе.

  • Приложение не должно быть помечено как распространяемое.

  • Контейнер не обязательно должен быть распределенным контейнером.

  • Контейнер может поддерживает другие способы переноса объектов.

Так что это значит? Ну, я думаю, это означает, что очевидное требование, чтобы ваши объекты сессий реализовали Serializable, проистекает из вашего выбора контейнера И способа, которым вы выбрали реализацию веб-приложения. Гипотетически вы могли бы изменить эти варианты.

0 голосов
/ 27 января 2019

Весь сеанс сервлета может быть сериализован на диск или другое хранилище в любой момент.Поэтому все объекты в нем должны быть сериализуемыми.

...