Considerações sobre Conexão ao Migrar Servlets, JSPs (JavaServer Pages) ou Beans Corporativos de Sessão

Alterações de Comportamento Contrário

O Comutador na Alocação de Conexões Compartilháveis e Não-Compartilháveis

Para módulos J2EE 1.2 utilizando origens de dados Versão 4, o WebSphere Application Server emite conexões não compartilháveis para arquivos JSP, servlets e beans de sessão corporativos. Todos os outros componentes de aplicativos são conexões emitidas que podem ser compartilhadas. No entanto, para J2EE 1.3 e módulos posteriores, o servidor de aplicativos emite conexões compartilháveis para todos os recursos denominados de forma lógica (recursos ligados a referências individuais), a menos que você especifique as conexões como não compartilháveis nas referências de recursos individuais. A utilização de conexões compartilháveis neste contexto tem os seguintes efeitos:

• Todas as conexões que são recebidas e usadas fora do escopo de uma transação do usuário não são retornadas para o conjunto de conexões livre até o método de encapsulação retornar, mesmo quando a manipulação de conexões emite uma chamada close().
• Todas as conexões que são recebidas e usadas fora do escopo de uma transação do usuário não são compartilhadas com outras instâncias do componente (ou seja, outros servlets, arquivos JSP ou enterprise beans). Por exemplo, o bean de sessão 1 obtém uma conexão e, em seguida, chama o bean de sessão 2 que também obtém uma conexão. Mesmo se todas as propriedades forem idênticas, cada bean de sessão receberá sua própria conexão.

Se não prever essa mudança no comportamento da conexão, a forma como você estrutura o código de seu aplicativo pode levar a um uso excessivo de conexões, especialmente nos casos de inclusões de JSP, beans de sessão que são executados dentro das transações locais sobre conexões que podem ser compartilhadas, rotinas RequestDispatcher.include(), rotinas RequestDispatcher.forward() ou chamadas desses métodos para outros componentes. Consequentemente, é possível enfrentar a interrupção da sessão, o tempo limite da sessão ou a deficiência da conexão.

Cenário de Exemplo

O servlet A estabelece uma conexão, conclui o trabalho, consolida a conexão e chama close() na conexão. Em seguida, o servlet A chama o RequestDispatcher.include() para incluir o servlet B, que executa as mesmas etapas que o servlet A. Como a conexão do servlet A não retorna para o conjunto livre até que ele retorne do método atual, duas conexões agora estão ocupadas Desse modo, mais conexões do que o esperado podem estar em uso no aplicativo. Se essas conexões não forem consideradas na configuração de Max Connections no conjunto de conexões, esse comportamento poderá causar uma falta de conexões no conjunto, o que resulta em exceções ConnectionWaitTimeOut Se o connection wait timeout não estiver ativado ou se o connection wait timeout estiver configurado para um número grande, esses encadeamentos poderão parecer interrompidos porque eles estão aguardando conexões que nunca foram retornadas para o conjunto. Os encadeamentos que aguardam novas conexões não retornarão aquelas que eles estão utilizando atualmente se as novas conexões não estiverem disponíveis.

Resolução

Para resolver esses problemas:

1. Utilize conexões não compartilhadas.

   Se você usar uma conexão não compartilhada e não estiver em uma transação do usuário, a conexão será retornada ao conjunto livre quando uma chamada close() for emitida (supondo que confirme ou retroceda a conexão).

2. Aumente o número máximo de conexões.

   Para calcular o número de conexões necessárias, multiplique o número de encadeamentos configurados pelo nível mais profundo do aninhamento de chamadas do componente (para as chamadas que utilizam conexões). Consulte a seção Cenário de Exemplo para obter uma descrição do aninhamento de chamada...