Failover de Bean de Sessão com Preservação de Estado para o Contêiner de EJB
É possível usar WebSphere Application Server para construir aplicativos que usam beans de sessão stateful que não são limitados por falhas de servidor inesperadas. O produto usa as funções do Data Replication Service (DRS) e do Workload Management (WLM) para que você possa ativar o failover do bean de sessão stateful.
- Você quer ativar failover para todos os aplicativos, com exceção de um único aplicativo. Para fazer isso, ative o failover no nível do contêiner de EJB e substitua a configuração no nível do aplicativo para desativar o failover no aplicativo único.
- Você deseja ativar failover para um único aplicativo instalado. Para fazer isso, desative o failover no nível do contêiner de EJB e, depois, substitua a definição no nível do aplicativo para ativar failover no aplicativo específico.
- Você deseja ativar failover para todos os aplicativos, com exceção de um único módulo de um aplicativo. Para fazer isso, ative failover no nível do contêiner de EJB, depois substitua a definição no nível do aplicativo do módulo para desativar o failover no módulo específico.
- Você deseja ativar failover para um único módulo EJB instalado. Para fazer isso, desative o failover no nível do contêiner de EJB e substitua a definição no nível do módulo EJB para ativar failover no módulo EJB específico.
- Ativando ou Desativando o Failover do Bean de Sessão com Preservação de Estado com o Painel Contêiner EJB
- Ativando ou Desativando o Failover do Bean de Sessão com Preservação de Estado com o Painel Aplicativos Corporativos
- Ativando ou Desativando o Failover do Bean de Sessão com Preservação de Estado com o Painel Módulos EJB
Política de Ativação de Bean de Sessão com Preservação de Estado com Failover Ativado
É possível especificar uma política de ativação para beans de sessão stateful durante a montagem de aplicativo. É importante considerar que a única vez que o contêiner do EJB se prepara para o failover, replicando os dados de bean de sessão com preservação de estado, é quando o bean de sessão com preservação de estado é passivado. Se você configurar o bean com uma política de ativação ativa uma vez, que é o padrão, o bean não é passivado rapidamente o suficiente para ser útil para o failover do bean de sessão stateful. Portanto, quando você ativa o failover, o contêiner EJB ignora a política de ativação configurada para o bean e automaticamente usa a política de ativação ativar no limite da transação. Essa ação assegura que o bean é passivado e seus dados são replicados sempre que ele estiver inscrito em uma transação que concluir.

O Bean de Sessão com Preservação de Estado Utiliza as Unidades de Trabalho Gerenciadas por Contêiner ou Unidades de Trabalho Gerenciadas por Bean com o Failover Ativado
As unidades de trabalho relevantes nesse caso são transações e sessões de atividade. O produto suporta failover do bean de sessão stateful para container-managed transactions (CMT), bean-managed transactions (BMT), container-managed activity sessions (CMAS) e bean-managed activity sections (BMAS). No entanto, nos casos gerenciados por contêiner, a preparação para failover ocorre apenas se você enviar um pedido para uma solicitação de método do enterprise bean que resulta em nenhuma conexão com o servidor. Além disso, se o servidor falhar após receber e reconhecer um pedido, o failover não ocorre. Ao ocorrer uma falha no meio de um pedido ou unidade de trabalho, o WLM não pode executar failover com segurança para outro servidor sem um código de compensação sendo executado pelo aplicativo. Quando isso acontece, o aplicativo recebe uma exceção do Common Object Request Broker Architecture (CORBA) e um código menor que especifica que o failover transparente não deve ocorrer porque a falha aconteceu durante a exceção de uma unidade de trabalho. Você deve gravar o aplicativo para verificar a exceção do CORBA e o código menor e compensar a falha. Após o código de compensação ser executado, o aplicativo pode tentar novamente os pedidos e se houver um caminho para um servidor de backup, o WLM roteia o novo pedido para um novo servidor principal para o bean de sessão stateful.
Para obter informações adicionais, consulte o tópico Códigos menores do Corba.
Para obter informações adicionais, consulte o tópico Gerenciamento de Carga de Trabalho para Todas as Plataformas Exceto z/OS.
O mesmo ocorre para unidades de trabalho ou sessões de atividade gerenciados por bean. No entanto, o trabalho gerenciado por bean apresenta uma nova possibilidade que deve ser considerada.
- Um método de um bean de sessão stateful que usa transação ou sessão de atividade gerenciadas por bean chama o método iniciar em uma UserTransaction que obteve a partir do objeto SessionContext. O método faz algum trabalho na unidade de trabalho iniciada, mas não conclui a transação ou a sessão antes de retornar ao responsável pela chamada do método.
- Após a chamada do método ser iniciada, o contêiner EJB suspende o trabalho que foi iniciado pelo método. Essa é a ação necessária para a especificação de Enterprise JavaBeans para unidades de trabalho gerenciadas por bean quando o bean é um bean de sessão stateful.
- O cliente inicia vários outros métodos no bean de sessão com preservação de estado. Cada chamada faz com que o contêiner de EJB resuma a transação ou a sessão de atividade suspensa, faça dispatch da chamada de método e, em seguida, suspenda o trabalho novamente antes de retornar ao responsável pela chamada.
- O cliente chama um método no bean de sessão com preservação de estado que conclui a transação ou sessão iniciada na etapa 1.
Esse cenário representa uma unidade de trabalho fixa gerenciada por bean. A transação ou sessão de atividade permanece por mais de um único método do bean de sessão com preservação de estado. Se um aplicativo utilizar um BMT ou BMAS fixo, e o servidor falhar após uma unidade de trabalho fixa ser concluída e antes de outra unidade de trabalho fixa ser iniciada, o failover obterá êxito. No entanto, se o servidor falhar antes da conclusão de uma transação ou sessão de atividade fixa, o failover não obterá êxito. Em vez disso, quando o processo de failover rotear o pedido do bean de sessão com preservação de estado para um novo servidor, o contêiner de EJB detectará que a falha ocorreu durante uma transação ou sessão de atividade fixa ativa. Nesse momento, o contêiner de EJB inicia uma exceção.
Esse processo indica que o failover para unidades de trabalho gerenciadas por contêiner e gerenciadas por bean não é bem-sucedido se a transação ou a sessão de atividade ainda estiver ativa. A única diferença é que uma exceção ocorre para unidades de trabalho gerenciadas por bean.
Considerações de Design do Aplicativo
- Para evitar a exceção descrita na seção anterior, você é encorajado a gravar o seu aplicativo para configurar beans de sessão stateful para usar container-managed transactions (CMT) em vez de bean-managed transactions (BMT).
- Se você deseja failover e seu aplicativo cria uma sessão de HTTP ou um bean de sessão stateful que armazene uma referência a um outro bean de sessão stateful, o administrador deve assegurar que a sessão de HTTP e o bean de sessão stateful estejam configurados para usar o mesmo domínio de replicação do data replication service (DRS).
- Não use uma referência local e uma remota
para o mesmo bean de sessão stateful.
Normalmente uma instância de bean de sessão com preservação de estado com uma determinada chave primária pode existir apenas em um único servidor em um determinado momento. O failover pode fazer com que o bean seja movido de um servidor para outro, mas ele nunca existirá em mais de um servidor ao mesmo tempo. No entanto, alguns cenários improváveis podem resultar na mesma instância de bean (mesma chave primária) existente em mais de um servidor simultaneamente. Quando isso acontece, cada cópia do bean desconhece a existência da outra e nenhuma sincronização ocorre entre as duas instâncias para assegurar que elas tenham os mesmos dados de estado. Portanto, seu aplicativo recebe resultados imprevisíveis.
Atenção: Para evitar essa situação, é necessário lembrar que com o failover ativado, seu aplicativo nunca deve obter ambas: uma referência local (EJBLocalObject) e uma remota (EJBObject) para a mesma instância de bean de sessão stateful. - Evite o uso de
métodos assíncronos remotos em beans de sessão stateful.
Quando um método assíncrono é chamado, o pedido de método assíncrono é enfileirado pelo servidor remoto e um objeto Futuro é retornado para o cliente. Como o pedido de método é enfileirado somente no servidor com a instância de bean de sessão stateful, o objeto Futuro é ligado àquele servidor e não falha. Se for necessário usar métodos assíncronos remotos para beans de sessão stateful, grave o aplicativo para detectar quando uma chamada para o objeto Futuro falha e faça uma chamada síncrona para o bean de sessão stateful para determinar se a transação que foi iniciada pelo método assíncrono foi concluída com êxito.
-
Evite fazer referência a cronômetros EJB não persistentes na instância de bean de sessão stateful quando failover estiver ativado.
Se um bean de sessão stateful incluir um identificador para uma instância de cronômetro não persistente criada automaticamente ou programaticamente, o identificador é inválido após o bean de sessão stateful falhar e a exceção javax.ejb.NoSuchObjectLocalException ocorre quando esse identificador for usado. Se o aplicativo precisar fazer referência a cronômetros não persistentes em beans de sessão stateful, grave o aplicativo para responder pelo identificador inválido.
Atenção: Identificadores para cronômetros persistentes criados automaticamente ou programaticamente em beans de sessão stateful falharão e podem ser usados após um failover do bean de sessão stateful.
![[z/OS]](../images/ngzos.gif)
Apenas para usuários do z/OS
- Múltiplos Servidores
- Configurando a Reinicialização e Recuperação no Mesmo Nível
- Clusters nos Quais Beans de Sessão Stateful Podem Ser Implementados
Como o produto z/OS possui uma região de controle e regiões servidoras e o produto WebSphere Application Server, Network Deployment não possui, há um cenário de failover que é exclusivo para z/OS, que é o failover de uma região servidora para outra região servidora (perda de um servidor sem perda do controlador).
Se você usar a técnica baseada em HFS no z/OS, continue com essa técnica.
Em um servidor z/OS não gerenciado, failover de bean de sessão stateful entre servidores pode ser ativado. O failover ocorre apenas entre os servants de um determinado servidor não-gerenciado. Se um servidor z/OS não gerenciado tiver somente um servidor, ativar failover não tem efeito. Um servidor z/OS não gerenciado que possui failover ativado não falhar para um outro servidor z/OS não gerenciado. Para ativar failover em um servidor não gerenciado, consulte Ativando Failover de Servidores em um Servidor Não Gerenciado.