Является ли @Singleton Session bean правильным местом для управления объектами в разных сеансах?

Question

Я все еще изучаю соответствующие шаблоны Java EE и буду благодарен за советы по лучшим инструментам для использования в этой проблеме.

У меня есть система, которая должна управлять несколькими экземплярами интеллектуальных агентов. Клиенты могут создать новый экземпляр или получить доступ к желаемому экземпляру по имени. Несколько клиентов могут получить доступ к одному и тому же агенту одновременно.

Наш план подвергать операции на агентов через интерфейс REST, поэтому вызов может быть что-то вроде:

GET /sessions/ 
POST /sessions/{name} 
PUT /sessions/{name}/doanaction 

Эти сеансы не будут сохраняться в прошлом перезагрузки, так что я не ищу Ресурса управление.

Моя мысль заключалась в том, что мы могли бы использовать сеансовый компонент @Singleton для управления отображением имен агентам, а затем вставлять его в сеансовые компоненты @Stateless, которые предоставили бы утилиты методам веб-службам REST.

Я хочу убедиться, что я не злоупотребляю @Singleton здесь. Поскольку несколько клиентов могут обращаться к одному и тому же агенту, похоже, нет никакого способа использовать управление сеансами Java EE для облегчения управления объектами на всех сеансах. Существуют ли другие инъекционные объекты, которые я должен использовать, помимо бина сеанса @Singleton? Как правило, это правильный подход к использованию этой проблемы? Советы оценены!

Answer 1

Я не думаю, что какой-либо из механизмов механизма EJB подходит для понятия агента - объекта с состоянием, имеющего собственный жизненный цикл на сервере, доступного одновременно нескольким клиентам.

Агенты состояния без состояния не имеют состояния, а сеансовые бобы с состоянием предназначены только для одного клиента.

Таким образом, возможно создание схемы из состояния агента из объекта в объект AgentState. Затем сохраните состояние каждого агента в ConcurrentHashMap, индексированном по имени агента. Карту хэша можно было бы обернуть в bean-компоненте @Singleton.

Код контроллера REST может затем получить состояние агента по имени, создать экземпляр на лету агента new MyAgent(agentState), передав ему состояние, а затем выполнить некоторую операцию.

Состояние агента может быть одновременно извлечено из кеша несколькими клиентами. Ключ MyAgent код должен предотвратить повреждение состояния агента, получая блокировку на объект агента всякий раз, когда он выполняет сложные операции:

класс MyAgent {

public void someCompoundOperation() { 
    synchronized (agentState) { 
     ... 
     String propertyA = agentState.getPropertyA(); 
     ... compare A with something 

     agentState.setPropertyA(newA); 
     ... 
    } 
} 

Это позволит предотвратить условия гонки, когда два клиенты читают одно и то же значение свойства и одновременно принимают действие вместо ожидания, пока другой агент завершит и освободит состояние агента.