Как обрабатывать устаревшие соединения?

Question

Наше это приложение J2EE, использующее Struts-EJB-Hibernate на Websphere 6.1 поверх мэйнфрейма / DB2, которое было недавно перенесено в производство.

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

со второй попытки пользователь сможет войти в приложение. Я получаю точное сообщение об ошибке

empcom.ibm.websphere.ce.cm.StaleConnectionException: 
Execution failed due to a distribution protocol error that caused deallocation of the conversation.  
The command requested could not be completed because of a permanent error condition detected at the target system.  
DB2ConnectionCorrelator: AC100B80.A260.090107181206

Я включил опцию PRETEST в настройках webshere и дал интервал 60 секунд, но я все еще получаю эту проблему ..

Пожалуйста, поделитесь своими взглядами и помогите мне

Я могу дать вам больше деталей, если вам нужно.

Answer 1

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

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

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

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

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

Answer 2

я получил ответ за это

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

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