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

Question

Nous avons une demande de connexion à DB2 sous z / OS et, après un certain temps, il semble y avoir une limite de ressources étant frappé sur le côté de l'ordinateur central. Comme nous utilisons BIRT, il semble que le contrôle que nous avons sur le code JDBC est avec strophes dans l'URL elle-même. nous ne contrôlons Java directement sur la connexion ou des déclarations (à l'exception du SQL lui-même bien sûr) bien qu'il 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 en utilisant JDBC simplement arrêter et aucune donnée ne sera écrite dans le fichier journal. Faire un TSO NETSTAT sur l'ordinateur central montre environ 50 sessions en état ESTABLISHED.

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

J'ai googlé beaucoup de choses, dont certains semblent indiquer que vous devrez peut-être engager requêtes avant de fermer une session. Il se peut que les séances peuvent être être maintenues ouvertes parce qu'il ya quelque chose de mal dans le BIRT Code proche (au moins en termes de ce que DB2 attend).

Quelqu'un at-il vécu quelque chose comme ça avant? Comment avez-vous résoudre ce problème (le cas échéant)? Est-il possible de le résoudre en utilisant seulement les strophes d'URL JDBC ou code Javascript dans la conception du rapport?

FWIW, nous utilisons DB2 9.1 et BIRT 2.2.1.

Answer 1

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

Il se trouve qu'il ya un paramètre appelé IDTHTOIN dans la section DSN6FAC du travail assemblage de paramètres DB2 / lien (en général 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 fils de DDF et zéro signifie « pas de temps mort ».

Un réglage à 180 résoudre notre problème. ont été fermées les fils qui retenaient les verrous vers le bas s'ils n'avaient pas eu d'activité dans ces trois minutes. il mise à moins de 120 n'est pas utile, car les fils ne sont vérifiées toutes les deux minutes de toute façon (en V9 DB2 au moins).

Vous devez également définir CMTSTAT=INACTIVE pour protéger les sujets bien comportés (ceux qui ont libéré tous leurs verrous de ressources mais tenant toujours le fil ouvert).

Gardez à l'esprit c'était correct pour notre problème particulier étant donné que les discussions étaient des rapports. Leur comportement était telle que l'a ouvert une session, a obtenu les données des rapports, puis n'a pas besoin de la session plus. Si vous avez des séances de longue durée, vous devez être prudent (bien que toute session qui maintient les verrous pendant plus de trois minutes est suspect de toute façon).

Vous devez modifier l'élément DSNTIJUZ, exécuter le travail, puis soit recycler l'instance DB2 ou exécuter SET SYSPARM.

Merci aux BOD utiles chez IBM Australia (West Perth Lab) pour Nutting cela pour moi.