Exemplo: Verificação de Consistência Leitura-Leitura

A verificação de consistência Leitura-Leitura aplica-se somente aos beans LifeTimeInCache cujos dados são lidos de outra transação.

Cenário de uso

Para intenções de acesso destinadas a RR (leitura repetível), isso significa que o produto verifica se os dados são consistentes com os do armazém de dados e assegura que ninguém os atualize após a verificação. Para Intenções de Acesso que sejam para RC (Read Committed), significa que o produto verifica se os dados são consistentes no ponto de verificação, mas não garante que os dados não serão alterados após a verificação. Isso torna o comportamento do bean LifeTimeInCache igual ao dos beans não LifeTimeInCache.

Você tem três opções para definir a verificação de consistência, conforme mostram os seguintes cenários referentes ao cálculo dos juros na conta bancária de "Ann". Em cada caso, o armazém de dados é compartilhado por esse aplicativo CMP (persistência gerenciada por contêiner) EJB (Enterprise JavaBeans) para calcular os benefícios e outros aplicativos, como BMP (persistência gerenciada por bean) EJB, JDBC (Java Database Connectivity) ou aplicativos legados. Além disso, em cada caso, a conta EJB é configurada como um bean long-lifetime.

NENHUM

  • O servidor é iniciado.
  • O Usuário 1 na Transação 1 chama Account.findByPrimaryKey("10001"), os dados da conta para Ann são lidos do banco de dados, com um saldo de $100.
  • O registro de Ann é armazenado em cache pelo PM (Persistence Manager) no servidor.
  • O Usuário 2 grava uma chamada JDBC e altera o saldo para $120.
  • O Usuário 3 na Transação 2 chama Account.findByPrimaryKey() para a conta "10001", os dados de Ann são lidos do cache, com um saldo de $100.
  • Calcule os juros de Ann, mas o resultado poderá não estar correto devido à questão da integridade de dados.

Verificação Leitura-Leitura AT_TRAN_BEGIN

  • O servidor é iniciado.
  • O Usuário 1 na Transação 1 chama Account.findByPrimaryKey("10001"), os dados da conta para Ann são lidos do banco de dados, com um saldo de $100.
  • O registro de Ann é armazenado em cache pelo PM (Persistence Manager) no servidor.
  • O Usuário 2 grava uma chamada JDBC e altera o saldo para $120.
  • O Usuário 3 na Transação 2 chama Account.findByPrimaryKey() para a conta "10001", os dados de Ann são lidos do cache, com um saldo de $100.
  • O PM executa a verificação leitura-leitura na conta de Ann e descobre que o saldo de 100 foi alterado. Ele emite uma consulta de banco de dados para recuperar o saldo de $120, e os dados de Ann no cache são atualizados.
  • Calcule os juros de Ann, continue com a transação porque a integridade de dados está protegida.

Verificação Leitura-Leitura AT_TRAN_END

  • O servidor é iniciado.
  • O Usuário 1 na Transação 1 chama Account.findByPrimaryKey("10001"), os dados da conta para Ann são lidos do banco de dados, com um saldo de $100.
  • O registro de Ann é armazenado em cache pelo PM (Persistence Manager) no servidor.
  • O Usuário 2 grava uma chamada JDBC e altera o saldo para $120.
  • O Usuário 3 na Transação 2 chama Account.findByPrimaryKey() para a conta "10001", os dados de Ann são lidos no banco de dados, com saldo de $100.
  • Calcule os juros de Ann.
  • Durante o final da transação 2, o PM executa a verificação leitura-leitura na conta de Ann e descobre que o saldo de 100 foi alterado.
  • O PM reverte a transação e invalida o cache. A transação falha e novamente a integridade de dados é protegida.

Í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_readread
Nome do arquivo: rejb_readread.html