Блог

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

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

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

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

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

Синглтоны

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

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

@Свойства открытого класса Singletonbean {

 private Properties props;
private int accessCount = 0;

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

public int getAccessCount() { ... }
  

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

 @EJB    private PropertiesBean propsBean;
  

…

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

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