В нашем приложении Seam есть секция опроса, в которой разговоры остаются активными до тех пор, пока страница остается открытой в окне / вкладке браузера, что позволяет пользователю работать с несколькими экземплярами объекта одновременно, без истечение срока разговора на «неактивных» страницах, когда они заняты на другой.
Все работает нормально, но время от времени мы получаем страшное исключение одновременного вызова разговора, когда поток опроса отправляет запрос, пока другой (длительный) выполняется. Мы установили довольно большое значение параметра concurrent-request-timeout (20 с), и большую часть времени страницы возвращаются менее чем за 2 с. Однако существуют ситуации, когда пользователи имеют дело с большими объемами данных (и они готовы ждать загрузки этих страниц, независимо от того, сколько времени это займет), поэтому мы не можем ничего сделать с точки зрения общей оптимизации.
То, что мы ищем, это способ проверить (в центральном фильтре, через который проходят все запросы), есть ли блокировка в данном диалоге, не пытаясь получить ее (чтобы не вызывать исключение, если есть замок на это уже). У нас есть средства для определения того, имеем ли мы дело с одним из этих фоновых потоков (мы делаем это для управления сеансом, поэтому они расширяют диалоги, но не сеанс в целом). Если мы сможем определить, что диалог уже используется, мы могли бы просто пропустить обработку этого потока опроса, так как его услуги не понадобятся в это конкретное время (разговор используется, так что нет опасности его истечения).
TLDR: проверить, не заблокирована ли беседа шва, не пытаясь получить к ней доступ (это может привести к срабатыванию исключения одновременного вызова к беседе)
Любые указатели, предложения, с благодарностью.