Frapper une limite sous z/OS avec le pilote DB2 Connect JDBC t4

Question

Nous avons une application qui se connecte à DB2 sous z/OS et, après un certain temps, il semble y avoir une limite de ressources sur le côté mainframe. Depuis que nous utilisons BIRT, il semble que le seul contrôle que nous avons sur le code JDBC est avec des strophes dans l'URL elle-même. Nous n'avons pas de contrôle Java direct sur la connexion ou les instructions (sauf pour le SQL lui-même bien sûr), bien que cela puisse être possible en utilisant Javascript dans la conception du rapport. Ainsi, nous pouvons activer le débogage avec quelque chose comme:

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

Finalement, l'application à l'aide JDBC simplement arrêter et aucune donnée ne sera écrite dans le fichier journal. Faire un TSO NETSTAT sur le mainframe montre environ 50 sessions dans l'état ESTABLISHED.

Maintenant, nous savons que c'est un problème du côté de l'ordinateur central depuis, quand il arrive, aucune connexion JDBC à cette instance fonctionnera (de tout client). À ce stade, nous devons redémarrer la base de données pour continuer.

J'ai parcouru pas mal de choses, dont certaines semblent indiquer que vous devrez peut-être commettre requêtes avant de fermer une session. Il se peut que les sessions soient maintenues ouvertes parce qu'il y a quelque chose qui ne va pas dans le code de fermeture de BIRT (au moins en termes de ce que DB2 attend).

Est-ce que quelqu'un a déjà vécu quelque chose comme ça? Comment l'avez-vous résolu (le cas échéant)? Existe-t-il un moyen de le résoudre en utilisant uniquement les strophes d'URL JDBC ou le code Javascript dans la conception du rapport? FWIW, nous utilisons DB2 9.1 et BIRT 2.2.1.

Answer 1

Cela a été résolu dans un autre forum, je copie la solution ici pour la postérité.

Il se trouve qu'il ya un paramètre appelé IDTHTOIN dans la section DSN6FAC du travail de l'ensemble des paramètres DB2/link (généralement db2prefix.SDSNSAMP(DSNTIJUZ) si votre configuration peut être différente) qui a été mis à zéro dans notre cas. Ce paramètre est le IDLE TIME OUT pour les threads DDF et zéro signifie "pas de délai".

Le réglage à 180 a résolu notre problème. Les fils qui retenaient les serrures étaient fermés s'ils n'avaient eu aucune activité pendant ces trois minutes. Le paramétrer à moins de 120 n'est pas utile car les threads ne sont vérifiés que toutes les deux minutes (dans DB2 v9 au moins).

Vous devez également définir CMTSTAT=INACTIVE pour protéger les threads bien élevés (ceux qui ont libéré tous leurs verrous de ressources mais maintiennent le thread ouvert). Gardez à l'esprit que c'était correct pour notre problème particulier puisque les discussions étaient pour les rapports. Leur comportement était tel que l'ouverture d'une session, obtenait les données pour le reporting, puis n'avait plus besoin de la session. Si vous avez des sessions de longue durée, vous devez faire attention (bien que toute session qui détient des verrous pendant plus de trois minutes soit suspecte de toute façon). Vous devez modifier le membre DSNTIJUZ, exécuter le travail, puis recycler l'instance DB2 ou exécuter SET SYSPARM.

Merci aux organismes d'IBM Australie (West Perth Lab) pour avoir trouvé ça utile pour moi.