Configuração da Fila de JMS para MessageDriven Bean

Então, só conheço as vias programáticas de fazer isso. Quando seu MDB recebe a mensagem, você tem a opção de configurar qual o tipo de reconhecimento da mensagem que ele faz. Se você quer usar isso com persistência, basta enviar o ACK depois de persistir o dado em banco. Imagino que existam mecanismos ainda melhores para fazer isso, mas aí, eu já desconheço.

[]'s

Poderia explicar melhor?

Vamos lá:

Happy day scenario ( ou seja, banco está online e operacional):

1. Seu MDB recebe a mensagem;
2. Persiste os dados em banco;
3. O MDB envia ACK para o gerenciador de mensagens.

Em caso de banco offline:

1. Seu MDB recebe a mensagem;
2. Tenta fazer a persistência;
3. Quando a persistência falhar, deixa de enviar o ACK para o gerenciador.

Isto vai fazer com que o gerenciador JMS tente entregar as mensagens de tempos em tempos, até que uma delas tenha sucesso.

[]'s

Obrigado alexandre…

Essa feature é configurado no próprio AS…certo? Cada um tem um forma diferente de fazer isso…
Vc ja fez?

Achei um da JBoss:

<address-settings> <address-setting match="jms.queue.MyQueue"> <dead-letter-address>jms.queue.MyDLQ</dead-letter-address> <redelivery-delay>0</redelivery-delay> ->>> Interval between redelivery attempts. <max-delivery-attempts>3</max-delivery-attempts> <max-size-bytes>10485760</max-size-bytes> <address-full-policy>BLOCK</address-full-policy> <message-counter-history-day-limit>10</message-counter-history-day-limit> </address-setting> </address-settings>

Para obrigar o reenvio da mensagem é preciso definir seu MDB como um durable subscriber, forçando assim o reenvio da mensagem até
que o seu MDB envei o ACK que a mensagem foi recebida.
Também será preciso definir seu MDB como CLIENT_AKNOWLEDGE, que permite o consumidor ter o controle do envio da ACK via

Isso depois de ter salvo a mensagem no banco, que foi a solução que o Alexandre Saudate falou.

Outra solução seria reenviar uma nova mensagem ao publisher com o id da message JMSMessageID, que não foi gravada no banco, e o publisher
recebendo esse id, pegaria em um cache interno com esse id a mensagem antiga e tentaria reenviar novamente para o subscriber. Se algum
server já faz isso, pelo jeito deve ser especifico de cada AS e não portável, eu também desconheço.
Mas o trabalho e as alterações seriam muitas, e com certeza a primeira solução seria a mais adequada e simples.