Как избежать исключения BusyConversationException в jsf

Я получаю BusyConversationException при навигации по страницам в моем проекте jsf. Это чаще всего происходит, если пользователь пытается перейти на другую страницу во время вызова ajax. Это также происходит, когда пользователь нажимает на ссылку сразу после нажатия на другую ссылку, не дожидаясь загрузки страницы.

Например, если пользователь нажимает на несколько ссылок, которые генерируются с помощью кода, подобного приведенному ниже, мы определенно получаем это исключение. Другой пример: скажем, пользователь вводит запрос в текстовое поле, а наше приложение делает запрос ajax для поиска этого запроса. Во время этого запроса, если пользователь нажимает на какую-либо кнопку для перехода на другую страницу, возникает также BusyConversationException.

<h:commandLink value="#{theProfile.profileName}"
               title="#{theProfile.profileName}"
               action="#{profileBean.aProfileSelected}">
               <f:setPropertyActionListener target="#{currentProfileWebBean.theProfile}" value="#{theProfile}"/>
</h:commandLink>

Я могу уловить этот тип исключения в классе ExceptionHandler, который расширяет класс ExceptionHandlerWrapper, но я не могу сохранить свое текущее состояние, и лучшее, что я могу сделать для этого случая, - перенаправить на главную страницу, когда возникает это исключение.

Есть ли какое-либо решение, чтобы избежать этого? Заранее благодарим за ответы и комментарии.

Ответ 1

Как упоминалось в других ответах, это происходит, если запрос ajax все еще обрабатывается или если событие ajax запускается до фактического нажатия на отправку командыLink или commandButton (например, событием изменения в поле ввода).

Нельзя избегать BusyConversationExceptions с onclick="preventEventPropagation(event)";, поскольку события AJAX не запускаются через распространение.

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

Проблема и решение более подробно объясняются в этом сообщении блога JSF2 AJAX/Отправить вопрос о проблеме.

Ответ 2

Я нашел это,

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

Контейнер гарантирует, что длительная беседа может быть связана не более чем с одним запросом за раз, блокируя или отклоняя одновременные запросы. Если контейнер отклоняет запрос, он должен связать запрос с новым переходным сеансом и выдать исключение типа BusyConversationException на этапе просмотра восстановления жизненного цикла JSF.

отсылайте здесь

Ответ 3

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

Избегайте распространения идентификатора беседы (cid), когда вам не нужен этот экземпляр беседы для целевого представления. В частности, несвязанные навигационные ссылки/кнопки должны подавлять параметр cid (не задумывались о том, как это сделать)
При запуске запроса, который использует активный сеанс, отключите другие элементы интерфейса, которые распространяют разговор, и поэтому могут вызывать параллельный доступ. Компоненты blockUI PrimeFaces Extracts Prime (или еще лучше) хорошо работают как полупрозрачный наложение, а также PrimeFaces p: ajaxStatus, чтобы показать состояние занятости.
Начните разговоры как можно позже. Это минимизирует случаи распространения долговременной беседы.

Я не думаю, что все это является полным решением. Как только cid заканчивается в строке местоположения (что происходит, когда вы выполняете неактивный пост после формы при активном разговоре), вы можете потерять контроль над временем доступа к этой цепочке из-за нескольких вкладок/окна, закладки и т.д.

Ответ 4

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

Я прочитал в одной из книг, busyConevrsation происходит с этим событием, происходит два действия, поэтому они сказали использовать: onclick="preventEventPropagation(event)"; в commandLink, чтобы предотвратить распространение события для этого клика. Поэтому я использовал то же самое, и он работал на меня.

Итак, теперь я не получаю исключение BusyConversationException:)