Beans Orientados por Mensagens - Suporte a Transações
Os beans orientados a mensagens podem manipular mensagens nos destinos (ou nós de extremidade) no escopo de uma transação.
Manipulação de transação ao usar o Serviço de Listener de Mensagens com JMS do IBM MQ
Há três casos possíveis, com base na configuração do descritor de implementação de bean acionado por mensagens escolhida: transação gerenciada por contêiner (obrigatória), transação gerenciada por contêiner (não suportada) e transação gerenciada por bean.
Nas configurações do descritor de implementação de bean acionado por mensagens, é possível escolher se o bean acionado por mensagens gerencia suas próprias transações (transação gerenciada por bean) ou se um contêiner gerencia transações em nome do bean acionado por mensagens (transação gerenciada por contêiner). Se você optar por transações gerenciadas por contêiner, no bloco de notas do descritor de implementação, é possível selecionar um tipo de transação de contêiner para cada método do bean para determinar se as transações de contêiner são necessárias ou não suportadas. O tipo de transação de contêiner padrão é necessário.
- Transação gerenciada por contêiner (obrigatória)
Neste caso, o servidor de aplicativos inicia uma transação global antes de ler qualquer mensagem recebida do destino e antes de o método onMessage() do bean acionado por mensagens ser chamado pelo servidor de aplicativos. Isso significa que outros EJBs chamados, por sua vez, pela mensagem e interações com recursos como bancos de dados podem todos ter o escopo definido dentro dessa única transação global, na qual a mensagem que chega foi obtida.
Se esse fluxo do aplicativo for concluído com êxito, a transação global será confirmada. Se o fluxo não for concluído com êxito (se a transação for marcada para retrocesso ou se ocorrer uma exceção de tempo de execução), a transação será retrocedida e a mensagem recebida será retrocedida para o destino do bean acionado por mensagens.
- Transação gerenciada por contêiner (não suportada)
Nesse caso não há nenhuma transação global, mas o provedor JMS ainda pode entregar uma mensagem a partir de um destino de bean acionado por mensagens para o servidor de aplicativos em uma unidade de trabalho. Você pode considerar isso como uma transação local, pois não envolve outros recursos em seu escopo transacional.
O servidor de aplicativos reconhece a entrega de mensagem na conclusão bem-sucedida do despacho onMessage() do bean acionado por mensagens (usando o modo de reconhecimento especificado pelo assembler do bean acionado por mensagens).
Entretanto, o servidor de aplicativos não executa um reconhecimento se uma exceção de tempo de execução não verificada for lançada a partir do método onMessage(). Assim, a mensagem é retrocedida para o destino do bean acionado por mensagens (ou é confirmada e excluída)?
A resposta depende se o ponto de sincronização é usado por seu provedor JMS e pode variar dependendo da plataforma operacional (em particular, a plataforma operacional z/OS pode contribuir para um comportamento diferente aqui).
Se o seu provedor JMS estabelecer um ponto de sincronização em torno do consumo de mensagens do bean acionado por mensagens nesse caso de transação gerenciada por contêiner (não suportado), a mensagem será retrocedida no destino após uma exceção não verificada.
Se um ponto de sincronização não for utilizado, a mensagem será excluída do destino depois de uma exceção não verificada.
Para obter informações relacionadas, consulte a nota técnica "O comportamento do MDB no z/OS é diferente de distribuído ao obter mensagens não persistentes no ponto de sincronização" em http://www.ibm.com/support/docview.wss?uid=swg21231549.
- Transação gerenciada por bean
Nesse caso, a ação é semelhante ao caso de transação gerenciada por contêiner (não suportado). Embora possa haver uma transação de usuário nesse caso, qualquer transação de usuário iniciada no despacho onMessage do bean acionado por mensagens não inclui o consumo da mensagem do destino do bean acionado por mensagens dentro do escopo de transação. Para fazer isso, utilize o cenário da transação gerenciada por contêiner (obrigatória).
Nova Entrega de Mensagem
Em cada um dos três casos anteriores, uma mensagem que é retrocedida para o destino do bean acionado por mensagens é, eventualmente, despachada novamente. Se o retrocesso original ocorre devido a um problema temporário do sistema, seria esperado que o novo despacho do bean acionado por mensagens com essa mensagem seja bem-sucedido no novo despacho. Porém, se a recuperação foi devida a um problema específico relacionado à mensagem, a mensagem pode ser repetidamente recuperada e ter um novo dispatch. Isso é conhecido como um cenário de mensagem suspeita.
Se o seu sistema de mensagens usar portas do listener, o servidor de aplicativos manipulará esse cenário, controlando a frequência com que uma mensagem específica é despachada e parando a porta do listener associada após a ocorrência de número especificado de novas tentativas de entrega dessa mensagem.
- Máximo de Novas Tentativas
- O parâmetro Máximo de Novas Tentativas especifica o número de vezes que o listener tenta entregar uma mensagem específica para uma instância de bean acionado por mensagens antes que o listener seja interrompido.
- Se esse parâmetro for configurado como 0, a porta do listener será parada após uma única falha de entrega bem-sucedida de uma mensagem.
Se o seu sistema de mensagens usar especificações de ativação, o cenário de mensagem suspeita será manipulado de uma maneira um pouco diferente. Considerando que as portas do listener controlam o número de vezes que uma mensagem específica falhou e foi entregue novamente, as especificações de ativação contam o número de falhas sequenciais na entrega de mensagem.
- Parar terminais automaticamente em falhas repetidas de mensagens
- Você deve certificar-se de que essa opção esteja selecionada.
- Essa propriedade suspende a entrega de mensagem para o terminal quando o Limite de mensagens com falha sequencial é atingido.
- Limite de mensagem com falha sequencial
- Esse parâmetro determina quantas entregas de mensagens podem falhar antes que a entrega de mensagens seja suspensa.
- Para ativar esse parâmetro, você deve ter a opção Parar terminais automaticamente em falha de mensagem repetida selecionada.
- Atraso entre novas tentativas de mensagem com falha
- Esse parâmetro especifica quanto tempo deve decorrer antes que uma mensagem, que falhou em ser entregue com êxito, seja entregue novamente.
- Se você especificar 0 para esse parâmetro, não haverá atraso antes que uma mensagem seja entregue novamente.
- Para ativar esse parâmetro, você deve ter a opção Parar terminais automaticamente em falha de mensagem repetida selecionada.
- Parar o terminal se a entrega de mensagem falhar
- Você deve certificar-se de que essa opção esteja selecionada.
- Essa propriedade suspende a entrega de mensagem para o terminal quando o Número de falhas sequenciais na entrega antes de suspender o terminal é atingido.
- Número de falhas sucessivas de entrega antes de suspender o terminal
- Esse parâmetro determina quantas entregas de mensagens podem falhar antes que a entrega de mensagens seja suspensa.
- Para ativar esse parâmetro, você deve ter a opção Parar o terminal se a entrega de mensagem falhar selecionada.
Como uma alternativa à dependência de seu servidor de aplicativos para parar a porta do listener ou a especificação de ativação se ocorrer um cenário de mensagem suspeita, é possível configurar o IBM MQ para resolver o problema. Para destinos de fila, especifique uma fila de restauração (BOQUEUE), e um valor do limite de restauração (BOTHRESH) no objeto de fila no IBM MQ. Para destinos de tópico, especifique uma fila de restauração (BOQUEUE), e o valor do limite de restauração (BOTHRESH) para as filas do sistema IBM MQ SYSTEM.DURABLE.MODEL.QUEUE e SYSTEM.NDURABLE.MODEL.QUEUE. Se você fizer isso, o IBM MQ manipulará a mensagem suspeita. Para obter mais informações sobre como manipular mensagens suspeitas, consulte a seção IBM MQ Usando Java™ da Biblioteca do IBM MQ.