Golpear un límite bajo z / OS con el controlador JDBC de DB2 Connect t4

Question

Tenemos una aplicación que se conecta a DB2 en z / OS y, después de un tiempo, parece que hay algún límite de recursos siendo golpeado en el lado de la unidad central. Puesto que estamos utilizando BIRT, parece que el único control que tenemos sobre el código JDBC es con estrofas en la propia URL. no tenemos control directo de Java través de la conexión o declaraciones (excepto para el propio SQL, por supuesto), aunque puede ser posible mediante el uso de Javascript en el diseño del informe. Así que podemos activar la depuración con algo como:

jdbc:db2://machine.com:1234/INSTANCE:traceFile=c:/db2.txt;traceLevel=-1;

Con el tiempo la aplicación mediante JDBC simplemente parar y no hay más datos se escriben en el archivo de registro. Haciendo un TSO NETSTAT en el mainframe muestra cerca de 50 sesiones en el estado de ESTABLISHED.

Ahora sabemos que esto es un problema en el lado de la unidad central ya que, cuando sucede, no conexión JDBC a esa instancia funcionará (de cualquier cliente). En ese punto, tenemos que reiniciar la base de datos para continuar.

He buscado en Google un buen montón de cosas, algunas de las cuales parece indicar que es posible que necesite para cometer consultas antes de cerrar una sesión. Puede ser que las sesiones pueden ser mantenidos abiertos porque hay algo mal en el código de cierre BIRT (al menos en términos de lo que espera de DB2).

¿Alguien ha visto algo como esto antes? ¿Cómo te arreglas (en su caso)? ¿Hay una manera de resolverlo utilizando sólo las estrofas URL JDBC o código Javascript en el diseño de informes?

Fwiw, estamos utilizando DB2 9.1 y BIRT 2.2.1.

Answer 1

Esto fue realmente resuelto en otro foro, estoy copiando la solución aquí para la posteridad.

Resulta que hay un parámetro llamado IDTHTOIN en la sección DSN6FAC del trabajo de montaje de parámetros de DB2 / enlace (generalmente db2prefix .SDSNSAMP(DSNTIJUZ) aunque su configuración puede ser diferente), que se pone a cero en nuestro caso. Este parámetro es el IDLE TIME OUT para roscas DDF y cero significa "sin tiempo de espera".

Al establecer esta a 180 resuelto nuestro problema. Los hilos que sujetaban las cerraduras se apagará si no hubieran tenido ninguna actividad en esos tres minutos. Si se establece en menos de 120 no es útil ya que los hilos de rosca sólo se verifican cada dos minutos de todos modos (en v9 DB2 al menos).

También debe establecer CMTSTAT=INACTIVE a proteger las roscas de buen comportamiento (las que han dado a conocer todos sus bloqueos de recursos, pero todavía se sujeta el hilo abierto).

Tenga en cuenta que esto estaba bien para nuestro problema particular ya que los hilos eran para los informes. Su comportamiento era tal que la abrieron una sesión, tiene los datos para la presentación de informes, entonces no necesitaba la sesión más. Si ha sesiones de larga duración, es necesario tener cuidado (aunque cualquier sesión que mantiene bloqueos durante más de tres minutos es sospechoso de todos modos).

Debe editar el miembro DSNTIJUZ, ejecute el trabajo, entonces o bien reciclar la instancia de DB2 o ejecute SET SYSPARM.

Gracias a los tíos votos en IBM Australia (Perth West Lab) para Nutting esto para mí.