Considerações sobre Ambientes em Cluster para Serviço de Cronômetro

Um um ambiente de servidor único, está claro qual instância do servidor deve chamar o método timeout de um determinado bean. Em um ambiente em cluster de vários servidores, há outras considerações que controlam o comportamento.

O WebSphere Application Server implementa o Enterprise JavaBeans (EJB) Timer Service. Com base nas necessidades comerciais, é possível usar os cronômetros persistentes ou cronômetros não persistentes. Os timers persistentes são úteis se você estiver criando um timer para um evento baseado em tempo que requeira garantia ou existência do timer além do ciclo de vida do servidor para sobreviver aos encerramentos e aos reinícios do servidor. Os timers persistentes iniciados anteriormente iniciam quando o servidor é iniciado e quando requerem uma instância do banco de dados. Cronômetros não persistentes não usam um armazenamento de dados e são cancelados quando o servidor de aplicativos é interrompido ou falha em permanecer em um estado ativo. Cronômetros não persistentes existem apenas no servidor no qual são criados. Em um ambiente em clusters, se o seu aplicativo EJB automaticamente cria um cronômetro não persistente e esse aplicativo é espelhado em diversos servidores, cada servidor terá seu próprio cronômetro não persistente que executará dentro desse ambiente do servidor. Um timer não persistente criado programaticamente é executado apenas no membro do cluster no qual ele foi criado.

Quando configurar um timer persistente em um ambiente de servidor em cluster de vários servidores, considere as seguintes possibilidades para a instância do servidor para chamar o método do tempo limite em um determinado bean:

  • Separar o banco de dados do serviço de cronômetro por processo do servidor ou membro de cluster. Essa é a configuração padrão. Apenas a instância do servidor ou o membro de cluster que criou o Cronômetro pode acessar o Cronômetro e executar o método timeout do bean. Se a instância do servidor não estiver disponível, o Cronômetro não será executado no tempo especificado e não será executado até que o servidor seja reiniciado. Além disso, se um enterprise bean chamar o método getTimers(), somente aqueles cronômetros criados na instância do servidor serão localizados. Isso pode provocar um comportamento inesperado se o bean corporativo tentar cancelar todos os cronômetros associados; por exemplo, quando o bean corporativo for removido. Essa configuração NÃO é recomendada para sistema em nível de produção.
  • Banco de dados de serviço de cronômetro comum ou compartilhado para o cluster. Os cronômetros podem ser criados e acessados em qualquer processo do servidor ou membro de cluster. Os cronômetros criados em um processo do servidor são localizados pelo método getTimers() em outros processos do servidor no cluster. Quando um bean de entidade for removido, todos os timers, não importa onde foram criados, são cancelados. No entanto, todos os cronômetros serão executados em um único servidor no cluster, ou seja, o método timeout do bean será executado para todos os cronômetros em um único servidor. Qual servidor executa os cronômetros varia de acordo com qual processo de serviço obtém uma trava nas tabelas do banco de dados comum. Se o servidor que executa os cronômetros ficar indisponível, outro servidor ou membro de cluster tomará o controle e começará a executar todos os cronômetros em seus horários planejados. Essa é a configuração recomendada para todos os sistema em nível de produção.
  • Evitar Problemas Evitar Problemas: Ao usar o serviço Cronômetro EJB em um aplicativo utilizando acesso ao banco de dados multiencadeado, o fluxo de aplicativo pode introduzir problemas de conflito.gotcha
    Para evitar isso, utilize a Intenção de Acesso wsPessimisticUpdate. Essa intenção de acesso faz com que o método localizador em seu aplicativo execute uma instrução select for update em vez de generic select. Isso, por sua vez, previne o conflito de escala de trava quando vários encadeamentos tentarem escalar suas travas para executar uma atualização.
Consulte as informações sobre o uso do serviço do timer EJB para enterprise beans para saber como configurar a origem de dados (banco de dados) para ser usada para cada serviço do timer de processo do servidor.
Evitar Problemas Evitar Problemas: Depois que a origem de dados para o serviço de cronômetro é alterada para apontar para um banco de dados diferente, o processo do servidor tenta automaticamente criar as tabelas requeridas nesse banco de dados no próximo início do servidor.gotcha
Se o ID do usuário associado ao início do processo do servidor não for autorizado para criar as tabelas do banco de dados no banco de dados de serviço do timer configurado, as tabelas deverão ser criadas manualmente.
Evitar Problemas Evitar Problemas: Quando usar o servidor proxy no produto, não defina um planejador no nível de célula se o planejador estiver configurado para uso para o serviço de cronômetro EJB. Fazer isso impede que cronômetros persistentes sejam executados. Isso pode ocorrer se o servidor proxy obter o lease do planejador. Como nenhum aplicativo é executado no servidor de proxy, não há nenhum código do aplicativo para manipular os eventos de timer que são enviados pelo planejador. gotcha
Evitar Problemas Evitar Problemas: Ao configurar um Cronômetro/Planejador EJB, lembre-se de que o planejador padrão usa o banco de dados Apache Derby baseado em arquivo simples por padrão para que seja possível ter rapidamente um ambiente com funcionamento adequado. NÃO use o banco de dados Derby para uso de produção. Além disso, o banco de dados Derby padrão não suporta um planejador de tarefa em cluster, nem um contêiner de lote em cluster.gotcha

Í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_timerservice_v8
Nome do arquivo: rejb_timerservice_v8.html