disponibilidad comandos clusvcadm cluster alta java hibernate exception web-applications db2

java - comandos - clusvcadm



¿Cómo manejar conexiones obsoletas? (2)

La nuestra es una aplicación J2EE, que utiliza Struts-EJB-Hibernate en Websphere 6.1 sobre Mainframe / DB2 back-end, que recientemente se movió a producción.

Estamos recibiendo una excepción de conexión obsoleta cuando el usuario inicia sesión en la aplicación por primera vez o algunas veces esta excepción se produce de forma intermitente.

en el segundo intento, el usuario puede iniciar sesión en la aplicación. El mensaje de error exacto que recibo es

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

He habilitado la opción PRETEST en la configuración webshere y le di el intervalo de 60 segundos, pero aún estoy recibiendo este problema.

amablemente comparte tus puntos de vista y ayúdame

Puedo darte más detalles si lo necesitas.


tengo la respuesta para esto

utilizando una conexión anterior a la prueba y una nueva conexión, podemos resolver este problema. La consulta previa a la prueba debe ser una consulta básica (seleccione sysdate de ...) que se ejecute en cualquier momento.

y el intervalo de tiempo debe ser máximo, por lo tanto, el servidor de aplicaciones no tendrá sobrecarga


Tuvimos el mismo problema al iniciar sesión por la mañana en uno de nuestros sistemas de producción. La solución era establecer el tamaño mínimo para el grupo de conexiones a cero.

Con un tamaño mínimo establecido en un valor mayor que cero (por ejemplo, uno), las conexiones caducadas se eliminan del grupo cuando se detectan como no válidas, pero algunas de ellas (en el ejemplo anterior, la última) permanecen en el grupo (si el tamaño mínimo es uno, una conexión permanece en el grupo, incluso si aún no es una conexión válida).

La próxima vez que una aplicación solicite una conexión, se servirá la no válida, lo que dará como resultado la excepción.

Al establecer el tamaño mínimo en cero, todas las conexiones no válidas se eliminan del grupo, por lo que no hay posibilidad de que la conexión servida a la aplicación todavía no sea válida (porque, si es válida, permanece en el grupo, si no lo está, se elimina del grupo).

El uso de la prueba preliminar podría ser una alternativa válida, pero requerirá un esfuerzo adicional, ya que cada vez que se proporciona la conexión a la aplicación, se prueba.