Обновление объекта введенного домена в Java EE 7 Приложение CDI

Question

Это может быть скорее концептуальный, чем технический вопрос, однако я надеюсь, что вы можете дать мне несколько советов о том, как действовать. Мы разрабатываем большое приложение Java EE 7, которое работает без гражданства и получает запросы от клиентов. Каждый запрос содержит идентификатор сеанса, и каждый сеанс содержит большое количество объектов домена, специфичных для сеанса. Мы создали класс RequestScoped, содержащий все методы-производители для наших объектов домена. Когда запрос приходит с идентификатором сеанса, мы вызываем метод setter для производителя, чтобы установить идентификатор сеанса в компоненте CDI производителя. Теперь, если один из классов RequestScoped по цепочке нуждается в одном из объектов домена, он имеет определение @Inject в начале класса, чтобы получить объект домена от производителя. Сам Продюсер имеет соединение с inmemory DB для извлечения объектов домена оттуда и сохранения их в локальной переменной для будущего использования в этом запросе.

На вопрос: Скажем, Bean A вводит объект домена X и изменяет некоторые свойства на X. Должен ли я вызвать метод «обновления» у моего производителя и передать объект домена X в качестве параметра или он автоматически обновляется в контекст? После инъекции в области запроса контейнер CDI создает прокси для доступа к фактическому компоненту. Будет ли этот прокси использоваться, как обычная ссылка? Например. если я вызову метод на моем вложенном bean-компоненте, обновит ли он компонент позади прокси-сервера?

Answer 1

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

Продюсер сам по себе имеет подключение к находящейся в заключении БД для извлечения объектов домена оттуда и сохранения их в локальной переменной для будущего использования в этом запросе.

Вы пытаетесь заново изобрести так называемые реплицированные, распределенные сеансы. Не делай этого. Используйте @SessionScoped beans и поддерживайте бизнес-логику в своем приложении и позволяйте инфраструктуре обрабатывать состояние приложения. Представьте себе, сколько лет вы смотрите на это приложение, когда ваш босс хочет обновить пользовательский интерфейс, а ваши клиенты требуют новых функций. Вы собираетесь не только поддерживать приложение, но и весь беспорядок из созданной вами багги распределенной структуры :(

Вместо этого вы можете использовать распределенную внутреннюю память для хранения вашего состояния сеанса и кэшировать его локально! Apache Tomcat/TomEE имеет большую поддержку для этого (я не уверен, что сервер приложений вы используете)

Взгляните:

• https://github.com/magro/memcached-session-manager (Использование Couchbase, Redis, Memcached, Hazelcast, GridGrain, или Apache Geode)
• http://community.gemstone.com/display/gemfire/Setting+Up+GemFire+HTTP+Session+Management+for+Tomcat (Специально для Gemfire)

Мы используем первый с большим успехом. Если экземпляр Tomcat обнаруживает идентификатор сеанса, он не имеет локального доступа, он извлекает его из сетки данных. Когда он завершит обработку запроса, он опубликует, что сеанс снова возвращается к сетке данных. Это очень быстро и прекрасно масштабируется.

Если сервер приложений делает не имеют возможность сделать это, вместо того, чтобы писать приложения в болезненном способе вы делаете, я хотел бы сосредоточить свои усилия на написание сеанса репликатора, как Memcached-сессии-менеджер. Удачи!