Использование EJB 3.1 Singleton Bean в качестве клиента для нескольких удаленных сессионных компонентов с сохранением состояния

Question

Я очень плохо знаком с EJB 3.1 и пытаюсь решить проблему на стороне сервера;возможно, кто-то может предложить какое-то руководство.

У меня есть конечный автомат, который представляет общее состояние нескольких пользователей в моем приложении.Я пытаюсь смоделировать этот конечный автомат как Stateful Session Bean;так как этим конечным автоматом представлено несколько пользователей, я представил компонент Singleton Session, который является действительным клиентом StateMachine, и все пользователи в конечном итоге становятся «клиентами» для компонента Singleton.Моя проблема возникает, когда я хочу жизненный цикл нескольких StateMachines на протяжении всего жизненного цикла приложения.

Мне бы хотелось, чтобы мой компонент Singleton («Менеджер») обрабатывал запросы клиентов и распространял их в соответствующий StateMachine - как бы я мог получить доступконкретные случаи этого Stateful bean?Чтобы добавить дополнительную сложность, я пытаюсь получить доступ к этим компонентам StateMachine удаленно (если бы они были локальными, я бы просто создал экземпляры этих вещей в качестве членов Manager).

В любом случае, я надеюсь, что это понятно,Я чувствую, что упускаю какой-то фундаментальный момент в дизайне EJB;Вы все скажете мне, если это так.

Answer 1

Синглеты были введены в EJB 3.1, предоставляя возможность делить состояние между несколькими экземплярами, как описано в Выборка EJB 3.1 .

Синглеты

Давным упущением в EJB API была возможность легко обмениваться состоянием между несколькими экземплярами компонента корпоративного компонента или между несколькими компонентами корпоративного компонента в приложении.В отличие от этого, модель программирования веб-приложений Java EE всегда предоставляла такую ​​возможность через объект ServletConfig.В EJB 3.1 это упущение было исправлено путем введения одноэлементных bean-компонентов, также известных как синглтоны.

Singleton - это новый тип сессионных bean-компонентов, который гарантированно будет создан один раз для приложения в конкретной JavaВиртуальная машина (JVM) *.Одиночный объект определяется с помощью аннотации @Singleton, как показано в следующем примере кода:

@ открытый класс Singleton PropertiesBean {

private Properties props;
private int accessCount = 0;

public String getProperty(String name) { ... }

public int getAccessCount() { ... }

} Поскольку это просто еще один вариант сессионного компонента,singleton может определять те же локальные и удаленные клиентские представления, что и bean-компоненты без сохранения состояния и состояния.Клиенты получают доступ к синглетам так же, как они обращаются к bean-компонентам без сохранения состояния и с состоянием, то есть через ссылку EJB.Например, клиент может получить доступ к вышеуказанному синглтону PropertiesBean следующим образом:

@EJB    private PropertiesBean propsBean;

...

String msg = propsBean.getProperty ("hello.message");Здесь контейнер гарантирует, что все вызовы для всех ссылок PropertiesBean в той же JVM обслуживаются одним и тем же экземпляром PropertiesBean.По умолчанию контейнер обеспечивает ту же гарантию многопоточности, что и для других типов компонентов.В частности, не более одного вызова допускается для доступа к конкретному экземпляру компонента в любой момент времени.Для синглетонов это означает блокировку любых одновременных вызовов.Однако это только режим параллелизма по умолчанию.Существуют дополнительные параметры параллелизма, которые обеспечивают более эффективный параллельный доступ к экземпляру синглтона.

Посмотрите Java EE6 Events о том, как отправлять уведомления с использованием событий.