Usar as extensões do WebSphere para definir a estratégia de simultaneidade

A estratégia de simultaneidade para o WebLogic especifica como o contêiner deve gerenciar o acesso simultâneo a um enterprise bean do tipo entidade. Esta regra detecta a presença do elemento <concurrency-strategy> no arquivo weblogic-ejb-jar.xml.

Há quatro estratégias de concordância do WebLogic que devem ser migradas para o WebSphere tradicional:

• Exclusive faz com que o WebLogic Server coloque um bloqueio restrito nas instâncias do EJB (Enterprise JavaBeans(TM)) da entidade quando o bean estiver associado a uma transação. Outros pedidos para a instância do EJB são bloqueados até que a transação seja concluída.
  
  
• A estratégia de simultaneidade ReadOnly é utilizada para beans de entidade somente de leitura. Ela carrega uma instância do banco de dados e, em seguida, disponibiliza cópias para cada transação, de forma que os pedidos possam continuar em paralelo. Um elemento relacionado chamado read-timeout-seconds especifica os segundos entre chamadas ejbLoad(). Um valor zero especifica que o bean somente de leitura não tem que ser recarregado do banco de dados.
  
  
• A estratégia de simultaneidade Database faz com que o WebLogic delegue pedidos de bloqueio para um bean de entidade ao armazenamento de dados subjacente. O WebLogic aloca uma instância do bean de entidade separada a cada transação e ativa o bloqueio e o armazenamento em cache a ser manipulado pelo banco de dados. Esta é a opção padrão.
  
  
• A estratégia de simultaneidade Optimistic não suporta nenhum bloqueio no contêiner EJB ou no banco de dados durante uma transação. O contêiner EJB verifica se algum dos dados atualizados por uma transação mudou antes da consolidação da transação. Se algum dado atualizado mudar, o contêiner EJB é revertido para a transação anterior.
  
  

No scanner de origem, a correção rápida fornecida para esta regra migra suas estratégias de simultaneidade definidas em weblogic-ejb-jar.xml para estratégias de simultaneidade definidas no arquivo de extensão do WebSphere EJB. É possível utilizar a opção de visualização da correção rápida para ver as mudanças antes de aplicar a correção rápida.

Origem scanner ações correção rápida:

Exclusivo

Para a estratégia Exclusive do WebLogic, as opções da cache do bean do WebSphere(R) Application Server a seguir são definidas para o bean correspondente:

• Ativar em é definido como ONCE.
• Carregar em é definido como ACTIVATION.

Estes parâmetros evitam chamadas para a função ejbLoad e serializam o acesso à instância de bean. Esta opção aumenta a utilização de memória mantendo o estado de persistência no cache mas pode fornecer melhor tempo de resposta se a instância de bean não for geralmente acessada simultaneamente. Essa é a Opção A de armazenamento em cache na especificação do EJB.

ReadOnly

Para a estratégia de ReadOnly do WebLogic, as opções a seguir do Cache do Bean do WebSphere Application Server são definidas para o bean correspondente:

• Ativar em é definido como ONCE.
• Carregar em é definido como INTERVAL.
• Intervalo de recarregamento é definido como o número apropriado de segundos entre os recarregamentos. Esse valor é obtido do elemento <read-timeout-seconds> do WebLogic que também é definido em segundos. Se <read-timeout-seconds> for configurado como 0 no WebLogic, então ejbLoad será chamado apenas quando a instância for trazida primeiro no cache. No WebSphere Application Server, um valor de intervalo de Recarga de número inteiro igual a 0 também faz com que o contêiner nunca recarregue o bean.

Database

Para a estratégia Database do WebLogic, as opções de cache do bean do WebSphere Application Server são definidas para o bean correspondente:

• Ativar em é definido como TRANSACTION.
• Carregar em é definido como TRANSACTION.

Esse é o padrão para o cache do bean do WebSphere Application Server. Como ele é o padrão, ele não tem que ser explicitamente configurado para cada um dos beans que utilizam a estratégia de simultaneidade do banco de dados. Todavia, a correção rápida não o define explicitamente. Essa estratégia também é referida como a Opção C de armazenamento em cache na especificação do EJB.

Optimistic

Para a estratégia Optimistic do WebLogic, o bloqueio otimista é utilizado no WebSphere. A intenção de acesso é definida no arquivo de extensão do WebSphere como wsOptimisticUpdate. Além disso, quando o mapa CMP é criado, a propriedade OptimisticPredicate é configurado como TRUE para todos os campos que são configurados no arquivo weblogic-cmp-rdbms-jar.xml como <verify-columns>. Essas colunas são verificadas para atualizações antes da consolidação das alterações para o banco de dados. Se uma alteração for detectada, a transação é revertida.