Почему HttpServlet реализует Сериализуемый?

Question

В моем понимании Servlet, Servlet будет создаваться контейнером, его метод init() будет вызван один раз, и сервлет будет жить как одиночка, пока JVM не отключится.

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

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

Answer 1

Технически, я считаю, что сервлет-контейнеру разрешено "пассивировать" объект сервлета на диск, так же, как могут быть сессионные компоненты EJB. Поэтому вы правильно задаете вопрос, если ваше приложение не будет работать из-за несериализуемых полей.

На практике я никогда не слышал о том, чтобы контейнер делал это, так что на самом деле это просто унаследованный багаж из дурных старых времен раннего J2EE. Я бы не волновался об этом.

Answer 2

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

Answer 3

Google, кажется, предполагает, что это было сделано, чтобы авторы контейнеров могли иметь возможность, если они этого хотят.

Вы правы в том, что сервлет не должен содержать членов, специфичных для сессии, на самом деле, я думаю, вы бы хотели иметь как можно меньше состояний. Если вы храните все в Session или ServletConfig, я думаю, вы сможете пережить сериализацию.

Answer 4

Сериализуемый используется как интерфейс маркера для атрибутов сеанса в распределенной среде.

SRV.7.7.2 Распределенные среды (JSR-154)

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

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

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

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

(...)

Контейнерный провайдер может обеспечить масштабируемость и качество обслуживания такие функции, как балансировка нагрузки и аварийное переключение с помощью с возможностью переместить объект сеанса и его содержимое из любого активного узла распределенная система к другому узлу системы. Если распределено контейнеры сохраняют или переносят сеансы для обеспечения качества сервисные функции, они не ограничены использованием собственной JVM Механизм сериализации для сериализации HttpSessions и их атрибутов. Разработчикам не гарантируется, что контейнеры будут вызывать методы readObject и writeObject для атрибутов сеанса, если они реализовать их, , но гарантируется, что Serializable закрытие их атрибуты будут сохранены .

Answer 5

Так же, как объекты Session сериализуются для выживания кэшей для тех сервлетконтейнеров, которые предоставляют параметр кластера, у контейнера может быть опция для передачи экземпляра сервлета также на другой узел кластера. Я просто догадываюсь здесь