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.
- 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.
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


