Bater algum limite sob z / OS com DB2 Connect JDBC driver de t4

Question

Temos uma aplicação ligar a DB2 em z / OS e, depois de um tempo, parece haver algum limite de recursos ser atingido no lado do mainframe. Como estamos utilizando BIRT, parece que o único controle que temos sobre o código JDBC é com estrofes na própria URL. não temos controle direto Java através da conexão ou declarações (exceto para o próprio SQL é claro), embora possa ser possível usando Javascript dentro do projeto de relatório. Assim, podemos ativar a depuração com algo como:

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

Finalmente, o aplicativo usando JDBC irá simplesmente parar e há mais dados serão gravados no arquivo de log. Fazendo uma TSO NETSTAT nas mostras de mainframe cerca de 50 sessões em estado ESTABLISHED.

Agora, nós sabemos que este é um problema no lado do mainframe uma vez que, quando isso acontece, não conexão JDBC para essa instância irá funcionar (de qualquer cliente). Nesse ponto, temos que reiniciar o banco de dados para continuar.

Eu pesquisei bastante um monte de coisas, algumas das quais parece indicar que você pode precisar para cometer consultas antes de fechar uma sessão. Pode ser que as sessões podem ser sendo mantido aberto porque há algo de errado no código BIRT próximo (pelo menos em termos do que espera do DB2).

Alguém já experimentou nada como isso antes? Como você corrigi-lo (se em tudo)? Existe uma maneira de resolvê-lo usando apenas as estrofes JDBC URL ou código Javascript dentro do design do relatório?

FWIW, estamos utilizando o DB2 9.1 e BIRT 2.2.1.

Answer 1

Este foi realmente resolvido em outro fórum, eu estou copiando a solução aqui para a posteridade.

Acontece que há um parâmetro chamado IDTHTOIN na seção DSN6FAC dos parâmetros do DB2 montagem / trabalho link (geralmente db2prefix .SDSNSAMP(DSNTIJUZ) embora a sua configuração pode ser diferente) que foi definido como zero no nosso caso. Este parâmetro é o IDLE TIME OUT para roscas DDF e zero significa "sem tempo limite".

A definição desse a 180 resolveu nosso problema. Os segmentos que foram bloqueios foram fechadas se que não tinham tido qualquer actividade nestes três minutos. Defini-lo para menos de 120 não é útil, pois os fios são verificadas apenas a cada dois minutos de qualquer maneira (em v9 DB2 pelo menos).

Você também deve conjunto CMTSTAT=INACTIVE para proteger tópicos bem comportados (aqueles que lançaram todos os seus bloqueios de recursos, mas são ainda segura a linha aberta).

Tenha em mente este foi bom para o nosso problema particular desde os fios eram para relatórios. Seu comportamento era tal que o abriu uma sessão, tem os dados para relatórios, então não precisa a sessão mais. Se você tiver de longa duração sessões, você precisa ter cuidado (embora qualquer sessão que mantém bloqueios por mais de três minutos é assim mesmo suspeito).

Você deve editar o membro DSNTIJUZ, executar o trabalho, então quer reciclar a instância do DB2 ou executar SET SYSPARM.

Graças aos bods votos em IBM Austrália (West Perth Lab) para nutting isso para mim.