Dicas de Resolução de Problemas de Intenção de Acesso

As perguntas frequentes a seguir que envolvem intenção de acesso estão respondidas.

O banco de dados Oracle falha quando nenhuma política de acesso é aplicada

Nenhuma política de intenção de acesso foi aplicada e o aplicativo é executado com um banco de dados DB2, mas falha com um banco de dados Oracle com a seguinte mensagem: com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1001E: Nenhum DataAccessSpec :FindAllCustomers. O armazenamento de dados backend não suporta a SQLStatement exigida por essa AccessIntent: (pessimistic update-weakestLockAtLoad)(collections: transaction/25) (resource manager prefetch: 0) (AccessIntentImpl@d23690a).

Se você não configurou a intenção de acesso, todos os seus dados são acessados sob o critério de intenção de acesso padrão (wsPessimisticUpdate-WeakestLockAtLoad). No DB2, o bloqueio mais fraco é o compartilhamento. Em bancos de dados Oracle, porém, o bloqueio mais fraco é a atualização; isso significa que a consulta SQL deve conter uma cláusula FOR UPDATE. Para evitar esse problema, tente aplicar uma política de intenção de acesso que suporte a simultaneidade otimista.

A chamada de um método localizador exibe uma exceção InconsistentAccessIntentException no tempo de execução

Isto pode ocorrer quando se utilizam critérios de intenção de acesso em nível de método para aplicar mais controle sobre como uma instância de bean é carregada. Essa exceção indica que o bean de entidade foi carregado anteriormente na mesma transação. Isto pode acontecer se você chamou um método multifinder que retornou a instância do bean com o critério de intenção de acesso X aplicado; você agora está tentando carregar o segundo bean novamente, chamando seu método findByPrimaryKey com a intenção de acesso Y aplicada. Ambos os métodos precisam ter o mesmo critério de intenção de acesso aplicado.

Da mesma forma, se a entidade foi carregada uma vez na transação utilizando um critério de intenção de acesso configurado em um finder, você pode ter chamado um método acessador de relacionamento gerenciado por contêiner (CMR) que retornou o bean de entidade configurado para carregar utilizando a intenção de acesso padrão dessa entidade.

Para evitar esse problema, certifique-se de que seu código não carregue a mesma instância de bean duas vezes dentro da mesma transação com diferentes critérios de intenção de acesso aplicados. Evite o uso de intenção de acesso no nível do método a menos que seja absolutamente necessário.

Uma exceção InconsistentAccessIntentException é exibida em um relacionamento gerenciado por contêiner com dois beans

Há dois beans em um relacionamento gerenciado por contêiner. O método findByPrimaryKey é chamado no primeiro bean e, em seguida, o método getBean2 é chamado e um método acessador CMR é chamado, na instância retornada, e uma exceção InconsistentAccessIntentException é exibida.

Você provavelmente está utilizando leitura antecipada. Quando carregou o primeiro bean, você fez com que o segundo bean fosse carregado sob o critério de intenção de acesso aplicado ao método finder para o primeiro bean. Entretanto, você configurou seu método acessador CMR do primeiro bean para o segundo com um critério de intenção de acesso diferente. Os métodos acessadores CMR são, na verdade, métodos finder disfarçados; o ambiente de tempo de execução se comporta como se você estivesse tentando alterar a intenção de acesso para uma instância que você já leu do armazenamento persistente.

Para evitar esse problema, os beans configurados em uma dica de leitura antecipada são todos dirigidos para carregar com o mesmo critério de intenção de acesso do bean para o qual a dica de leitura antecipada é aplicada.

Um Bean com um Relacionamento de um para Muitos com um Segundo Bean Exibe um Erro

Um bean com um relacionamento de um para muitos para um segundo bean exibe um erro UpdateCannotProceedWithIntegrityException quando uma instância do segundo bean é incluída na coleta do primeiro bean

Um bean com um relacionamento de um para muitos para um segundo bean exibe um erro UpdateCannotProceedWithIntegrityException quando uma instância do segundo bean é incluída na coleta do primeiro bean. O primeiro bean tem um critério de intenção pessimistic-update aplicado.

O segundo bean provavelmente tem um critério de intenção de leitura aplicado. Quando você adiciona o segundo bean à coleção do primeiro bean, você não está atualizando o estado do primeiro bean, está modificando implicitamente o estado do segundo bean. O segundo bean contém uma chave externa para o primeiro bean, que é modificado.

Para evitar esse problema, certifique-se de que ambas as extremidades do relacionamento tenham um critério de intenção de atualização aplicado se você esperar alterar o relacionamento no tempo de execução.


Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rejb_axifaq
Nome do arquivo: rejb_axifaq.html