Considerações sobre Conexão ao Migrar Servlets, JSPs (JavaServer Pages) ou Beans Corporativos de Sessão
Se planeja fazer upgrade para o WebSphere Application Server Versão 7.0 ou posterior e migrar aplicativos da versão 1.2 da especificação Java™ 2 Platform, Enterprise Edition (J2EE) para uma versão posterior, como a 1.4 ou o Java Platform, Enterprise Edition (Java EE), esteja ciente de que o produto aloca conexões compartilháveis e não compartilháveis de forma diferente para os componentes de aplicativos pós-versão 1.2. Para obter alguns aplicativos, essa diferença pode resultar na degradação de desempenho.
Alterações de Comportamento Contrário
Como o WebSphere Application Server fornece compatibilidade com versões anteriores com módulos aplicativos codificados para a especificação J2EE 1.2, é possível continuar a usar as fontes de dados de estilo Versão 4 ao migrar para o WebSphere Application Server Versão 7.0 ou posterior. Desde que você configure fontes de dados Versão 4 somente para módulos J2EE 1.2, o comportamento de seus componentes de aplicativos de acesso a dados não é alterado.
Se estiver adotando uma versão posterior da especificação J2EE juntamente com sua migração para o WebSphere Application Server Versão 7.0 ou posterior, no entanto, o comportamento de seus componentes de acesso a dados pode ser alterado. De forma específica, esse risco se aplica a aplicativos que incluem servlets, arquivos JSP (JavaServer Page) ou beans corporativos de sessão que são executados em transações locais sobre conexões compartilháveis. Uma alteração de comportamento nos componentes de acesso a dados pode afetar negativamente o uso das conexões nesses aplicativos.
Essa alteração afeta todos os aplicativos que contêm os seguintes métodos:
- RequestDispatcher.include()
- RequestDispatcher.forward()
- Inclusões de JSP (<jsp:include>)
Os sintomas do problema incluem:
- Interrupção de sessão
- Tempo limite de sessão
- Ficar sem conexões
O Comutador na Alocação de Conexões Compartilháveis e Não Compartilháveis
Para o s módulos J2EE 1.2 que usam as fontes 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 alteração 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, você pode 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, o qual executa as mesmas etapas que o servlet A. Como a conexão do servlet A não é retornada ao conjunto livre até retornar do método atual, duas conexões ficam ocupadas agora. Desse modo, mais conexões do que o esperado podem estar em uso no aplicativo. Se essas conexões não forem consideradas na definição do Máximo de Conexões no pool de conexão, esse comportamento poderá causar uma falta de conexões no pool, o que resultará em exceções ConnectionWaitTimeOut. Se o tempo limite de espera por conexão não estiver ativado, ou se o tempo limite de espera por conexão estiver definido como um número grande, esses encadeamentos podem parecer travados, porque eles estão aguardando conexões que nunca são retornadas ao 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:
- Utilize conexões não compartilhadas.
Se 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 você emitir uma chamada close() (assumindo que você confirme ou retroceda a conexão).
- 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çãoCenário de Exemplo para obter uma descrição do aninhamento de chamadas.