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