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.

Como você pode não querer ativar o failover para cada bean de sessão stateful que estiver instalado no contêiner Enterprise JavaBeans (EJB), pode substituir as configurações do contêiner EJB no aplicativo ou no nível de modelo EJB. É possível ativar ou desativar o failover em cada um desses níveis. Por exemplo, considere as seguintes situações:
  • 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.
Para obter informações sobre o failover do bean de sessão stateful a partir do console administrativo, consulte os tópicos a seguir:
  • 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.

Evitar Problemas Evitar Problemas: Quando o DRS recebe dados para replicar, o DRS replica os dados para os servidores de aplicativos N-1, em que N é o número de réplicas disponíveis. Se o servidor de criação e todos os servidores contendo as cópias de backup dos dados falharem ou forem interrompidos, os dados replicados serão perdidos, a menos que o consumidor do DRS replique novamente os dados.gotcha

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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

Para unidades de trabalho gerenciadas por bean, o processo de failover nem sempre pode detectar que uma BMT ou BMAS iniciada por um método do bean de sessão stateful não foi concluído. Então, é possível que o failover para um novo servidor possa ocorrer, apesar da unidade de trabalho falhar no meio de uma transação ou sessão. Como a unidade de trabalho é implicitamente revertida, o WLM comporta-se como se fosse seguro efetuar failover de forma transparente para outro servidor quando, na verdade, pode ser requerido algum código de compensação. Quando isso acontece, o contêiner EJB detecta esse comportamento no novo servidor e inicia uma exceção. Essa exceção ocorre no seguinte cenário:
  1. 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.
  2. 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.
  3. 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.
  4. 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

Considere as seguintes informações ao projetar aplicativos que usam o processo de failover do bean de sessão stateful:
  • 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]

Apenas para usuários do z/OS

O failover do bean de sessão stateful no WebSphere Application Server, Network Deployment para z/OS é levemente diferente daquele no produto WebSphere Application Server, Network Deployment. Além da solução de failover discutida aqui, usuários do z/OS também podem ativar failover entre servidores em um servidor não gerenciado. Para obter informações adicionais, consulte os tópicos:
  • 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.


Ícone que indica o tipo de tópico Tópico de Conceito



Í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=cejb_sfsbf
Nome do arquivo: cejb_sfsbf.html