Сегодня на работе у меня было обсуждение с моими коллегами и моим боссом о bean-компонентах без состояния / с состоянием (мы только что закончили проект с использованием JSF, это был первый раз, когда кто-то в этой компании сделал что-то связанное с JSF), и мой босс сказал что ему действительно не нравятся бины с сессионной областью (или даже с сферой беседы / KeepAlive). Одним из его аргументов было то, что если у нас есть, например, 4 Tomcats и есть запрос от пользователя, то мы не уверены, что он будет «захватываться» одним и тем же Tomcat каждый раз, и проблема в том, что если во время в первый раз, когда приходит запрос и создается сессионный компонент, он создается только на том Tomcat, а другие не знают об этом.
Одним из упомянутых им решений был так называемый «липкий сеанс», который заставляет запросы от конкретного пользователя каждый раз обрабатываться одним и тем же Tomcat. Второе решение, по его словам, будет хранить все данные в «представлении», но это будет означать сохранение всего состояния в POST, почему-то мне не очень нравится эта идея. Затем он упомянул о сохранении состояния в БД и запросе его, если поступает запрос, который требует его. Я думал, что это будет очень большой удар по производительности, но он сказал, что это действительно не будет проблемой, поскольку БД должны быть готовы к таким задачам.
Последнее решение, которое меня заинтересовало, - это Terracotta Server, который, исходя из того, что он сказал нам, должен хранить сессионный компонент для всех Tomcats (которые синхронизируются с ним, а затем, если поступают запросы, они ищут сессионные бобы внутри терракоты). Кажется, это круто и масштабируемо, но он сказал, что в действительности не видел, чтобы это когда-либо использовалось в больших профессиональных системах, верно? Я попробовал некоторую информацию об этом, но потерпел неудачу, что-то не так с Терракотой, которая мешает людям использовать это?