Почему HttpServlet реализует Serializable?

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

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

(...)

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