Resolvendo Problemas de Conflitos do JPA e de Tempos Limite da Transação
Os conflitos de banco de dados e os tempos limites de transação são resultados de contenção entre dois ou mais clientes que tentam acessar o mesmo recurso de banco de dados. O conflito é um caso especial em que há uma condição de bloqueio circular entre dois ou mais clientes, cada um bloqueado por outros, mas um pode continuar. Geralmente estes fenômenos não vêm a ser um erro de programação. Eles são causados pela lógica de negócios que acessa os recursos de banco de dados de modo complexo e interdependente.
Sobre Esta Tarefa
Ao usar as seguintes Boas práticas e estratégias, estas condições podem ser minimizadas.
Procedimento
- Identifique os recursos de banco de dados afetado que causaram o erro.
- Examinar as exceções (se houver) quando o erro ocorre pode dar pistas das entidades com falha que causaram a condição de falha.
- Se o provedor JPA padrão do WebSphere Application Server for usado, será possível ativar o grupo de rastreio “eclipselink.logging.level.sql” para aplicativos EclipseLink ou "openjpa.jdbc.SQL=all" para aplicativos OpenJPA para coletar as instruções SQL e informações de encadeamento dos recursos do banco de dados em questão. Ao coletar as informações, será possível localizar quais clientes e entidades são os artefatos que causaram a condição de falha.
- Para um cenário de uso mais complexo, poderá consultar a documentação do banco de dados para obter quaisquer ferramentas ou técnicas especializadas que podem ajudar a identificar os objetos e a transação que estão causando os problemas de contenção de dados.
- Quando os problemas são identificados, examine a lógica de negócios
que usa estes recursos para determinar que seu uso não cause nenhuma contenção
prolongada. Não há nenhuma solução prescrita para resolver problemas
de conflito e de tempo limite. Isso depende muito da complexibilidade da lógica
de negócios e dos relacionamentos da entidade.
O conceito básico para resolver os conflitos e tempos limites é minimizar o
tempo em que os recursos são mantidos mais que o necessário e permitir que
outros clientes acessem o mesmo recurso. Se a contenção for inevitável,
o aplicativo deverá estabelecer meios para recuperação quando estas condições com falha
ocorrerem. A seguir estão estratégias que podem ajudar a minimizar as condições de problema
e determinar se é possível aplicar um ou mais para resolver o problema:
- Certifique-se de que a lógica de negócios não bloqueie as entidades mais que o necessário. Um aplicativo JPA que for na maioria das vezes somente leitura deve usar as semânticas de bloqueio otimistas oferecidas pelo JPA por padrão. O JPA 2.0 introduz funções de bloqueio pessimistas que permitem que os aplicativos bloqueiem explicitamente a entidade de modo pessimista on demand. Você deve otimizar o número de bloqueios pessimistas que são aplicados a qualquer determinado momento. O sobrebloqueio aumenta a chance de conflitos e tempos limites e degrada a simultaneidade e o rendimento do aplicativo.
- Evite configurar o nível de isolamento de conexão da origem de dados para mais restritivo do que o necessário. O nível de isolamento possui o mesmo efeito que as semânticas de bloqueio pessimistas no nível de conexão. O JPA requer um nível de isolamento mínimo de "read-committed" para atingir um objetivo de integridade de dados básica. O nível de isolamento padrão do gerenciador de conexões do WebSphere Application Server é específico do banco de dados. Consulte o tópico de interfaces de programação para obter as informações de especificação de API JDBCConnectionSpec.
- Minimizar a duração de qualquer transação ativa. A transação ativa estendida possui o potencial para manter os recursos que forem necessários por outros clientes. Confirme qualquer transação assim que ela possuir todos os recursos concluídos.
- Otimizar a lógica de negócios para evitar interdependência da entidade. Se dois conjuntos de lógica de negócios usarem recursos semelhantes, considere atualizar os recursos na mesma ordem para anular dependência circular de conflito clássico. Isso depende do nível de isolamento que estiver sendo usado. Isso possui o mesmo efeito que aplicar bloqueio implícito para os recursos, conforme descrito na próxima estratégia.
- Usar o bloqueio pessimista para sincronizar acesso simultâneo ao recurso comum. Quando as estratégias anteriores não forem aplicadas na sua situação, o bloqueio pessimista será uma alternativa para sincronizar o acesso aos recursos comuns usados por clientes simultâneos diferentes. O aplicativo pode usar as funções de bloqueio pessimistas JPA 2.0 para bloquear outros clientes de acessar o recurso comum até a transação ser confirmada ou retrocedida. Aumentar o uso de bloqueio pessimista pode afetar a simultaneidade e o rendimento. O WebSphere Application Server JPA Access Intent também fornece outra alternativa para bloquear recursos de dados baseados na chamada de EJB ou no nome da tarefa definido pelo usuário.
- Manipular e recuperar-se de bloqueio e de exceção de tempo limite. A maioria dos servidores de bancos de dados possui um mecanismo de prevenção de conflito integrado. Quando ele detectar uma condição de conflito, a estratégia típica usada pelo banco de dados é cancelar uma das solicitações e permitir que a outra seja bem sucedida. Entretanto, a solicitação que é terminada é específica do banco de dados e não-determinista. Se um aplicativo permitir, será uma boa prática recuperar a condição de conflito e tentar novamente a operação.
Conceitos relacionados:
Tarefas relacionadas:
Referências relacionadas:


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_jpadeadlock
Nome do arquivo: tejb_jpadeadlock.html