Sexta-feira passada, postei em meu twitter que estou tocando um projeto que envolve MOM. Hammm… JMS, para ser mais específico… rsrsrs…. Bem, o fato é que este projeto acabou me motivando a escrever este post sobre o assunto transação e EJB3 Message-Driven Beans (MDB), apenas para fazer alguns lembretes e dar algumas dicas, já que este é um assunto fundamentalmente importante. Vamu que vamu então…
A primeira coisa importante a saber é que transações não são propagadas do produtor de mensagens JMS para o MDB que as consome, independentemente destes trabalharem com CMT ou BMT. Isso se dá pela própria natureza assíncrona de um sistema baseado em MOM, uma vez que uma mensagem pode levar horas para ser consumida, se assim fizer sentido ao sistema. Assim sendo, uma transação de um MDB está limitada ao escopo do método onMessage, que recebe e trata as mensagens.
A segunda coisa importante a saber é que quando o MDB faz o seu próprio gerenciamento de sua transação, a mensagem consumida não é parte transação. Ao passo que, se a transação do MDB for gerenciada pelo contêiner EJB, sim, a mensagem é parte da transação.
Sabendo essas duas coisas, somos levados a uma questão: O que acontece entãos se a transação falhar? Bem, está é a terceira coisa importante que precisamos saber. Sempre que o método onMessage completa sua execução sem erros, o contêiner EJB notifica ao provedor JMS reconhecendo o recebimento da mensagem. No entanto, se o correr uma RuntimeException durante a sua execução, o provedor JMS não receberá esta notificação de reconhecimento e, muito provavelmente, disponibilizará a mensagem para ser novamente consumida pelo MDB. Isso poderia causar um problema sério de loop infinito, em caso de poison messages, mas felizmente há antidoto para isso: Configurar o número máximo de tentativas de entrega de mensagens. Uff!!!
Como lidar então com exceções, rollback e reentrega de mensagens?
Há momentos em que a reentrega de mensagens é fundamental; e há momentos que não. Se ocorrer uma exceção de negócio, por exemplo, você não vai querer que a mensagem seja entregue novamente. Mas, se ocorrer um exceção por indisponibilidade de uma recurso (banco de dados, web service, etc), seria fundamental que a mensagem fosse entregue novamente, depois de algum tempo. Com isso em mente, vamos discutir um pouquinho o assunto.
Primeiro de tudo, não se esqueça que MDB’s não retornam exceções ao cliente que produziu a mensagem. Se a sua lógica de negócio em cima da mensagem produzida pelo cliente prevê uma exceção, pare e pense um pouco a respeito. Se você puder responder a ele com uma outra mensagem que ele (ou outro MDB responsável por notificar clientes) poderá consumir no provedor JMS, ótimo; caso contrario, esqueça, mensagens assíncronas não é uma opção para você.
Seguindo adiante com a solução, você precisa saber como MDB’s CMT ou BMT se comportam quando o assunto é transação. As diferenças básicas entre esses dois modelos de gerenciamento de transações são as seguintes:
Se seu MDB está baseado em CMT, significa que as mensagens que ele consume são parte da transação. Portanto, se a transação sofrer rollback, automaticamente, o consumo da mensagem também será revertido e o provedor JMS deverá tentar entregar a mensagem novamente.
Já, se seu MDB está baseado em BMT, significa que se a transação sofrer rollback o consumo da mensagem não será revertido, como acontece automaticamente no caso de CMT, e você poderá manter isso em segredo do provedor JMS, evitando que ele entregue a mensagem novamente. Ou, se fizer sentido ao seu requisito, você poderá notificá-lo do rollback de maneira bem simple e segura, basta lançar uma EJBException que é pá/pum.
Um pouco mais sobre Reconhecimento de Mensagem
A propriedade acknowlodgeMode, que determina o modo de reconhecimento da mensagem, pode ser definida como Auto-acknowledge ou Dups-ok-acknowledge. A primeria opção, instrui o contêiner EJB a notificar o reconhecimento da mensagem dentro do contexto da transação, seguindo as regras já citadas; e a segunda, o instrui a fazer isso num outro momento qualquer.
Essa propriedade pode ser ignorada, a menos que você esteja implementando um BMT ou um CMT com atributo de transação definido como NotSupported. Do contrario, o reconhecimento sempre ocontecerá no contexto da transação.
Se quiser saber mais, indico que você leia esse material.
Resumindo: Tome cuidado com suas exceções e não deixe que elas explodam sem mais nem menos, sem um tratamento adequado, nem nada, porque elas podem detonar suas transações e ainda causar problemas de negócio, com a reentrega de mensagens. Um bom log também vai muito bem, meu caro! 
Bom, é isso ai… Espero que te ajude!
E se você ainda não leu esses dois posts: Cuidado com suas exceções e Transacionando EJB3 Session Beans, quando tiver um tempinho, leia. Talvez lhe sejam úteis também.
Até a próxima!
