Несколько вызовов ajax jsf2 и ejb3.1

Question

У меня есть несколько живых графиков.В настоящее время у меня есть несколько ссылок по одной для каждого графика.Когда пользователь щелкает ссылку, загружается соответствующая диаграмма, и каждые 5 секунд делается ajax-вызов, чтобы вызвать метод действия в управляемой видовой области.Когда пользователь щелкает другую ссылку, предыдущий setinterval очищается, и тот же процесс повторяется для другого графика.Для всех этих диаграмм (ссылок) их соответствующие методы действий находятся в одном и том же видоизмененном управляемом бобе, который поддерживается одним EJB-компонентом, причем один метод обслуживания соответствует каждому методу действия.

Пока все хорошо.

Следующим шагом является наличие ссылки для одновременного отображения всех этих графиков в режиме реального времени.Теперь я знаю, что будет несколько асинхронных вызовов ajax.Я считаю, что сервлет (FacesServlet) обрабатывает все эти запросы в отдельном потоке.Но что происходит с Managed Bean и EJB.Нужно ли создавать отдельные управляемые компоненты (если МБ - это RequestScoped, создает ли JSF отдельный экземпляр для нескольких асинхронных запросов ajax) и отдельные ejbs?Я сейчас немного сбит с толку, и мне нужен полезный совет.Я хочу, чтобы они обрабатывались одновременно.

Спасибо.

Обновление:

Прежде всего благодаря bogdan.mustiata.

Теперь, так как я больше не получаю ответов, я попытаюсь прояснить ситуацию немного.

Что я действительно пытаюсь понять, это:

Когда у меня есть ViewScoped (илиSessionScoped) управляемый компонент и EJB без сохранения состояния -

1. Как обрабатывается запрос на стороне сервера?
2. Как обрабатываются множественные асинхронные запросы Ajaxна стороне сервера?

Я понимаю следующее:

1. Запрос отправляется на сервер.
2. FacesServlet запускает поток для каждого запроса.
   1. Выполнен метод действия Managd-bean.
   2. Экземпляр EJB предоставляется контейнером и выполняется соответствующий метод в EJB.

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

Так ли это?

Answer 1

Если ваши EJB @Stateless, это не имеет значения, вы в порядке.Если они @Session, то вам не повезло, так как в прошлый раз, когда я проверял (в EJB 3.0), вам не разрешалось вызывать несколько методов с состоянием EJBs одновременно.Существовал фреймворк с именем Seam, который мог сериализовать вызовы к EJB с отслеживанием состояния.

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

Обновление:

Я прочитал спецификацию для EJB 3.1 и текств 4.3.14 состояния:

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

Чтобы сделать вещи более увлекательными, он продолжает говорить:

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

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

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

Обновление: Вы никогда не получите экземпляр дляEJB, вы всегда получаете прокси, который будет вызывать EJB.В случае EJB без сохранения состояния ваш прокси в конечном итоге будет создавать новый EJB без сохранения состояния для каждого собственного вызова метода, и код EJB будет каждый раз запускаться на новом экземпляре.