Is there a way to rollback a JMS transaction, causing the JMS provider to move the message to another queue ( Like a dead letter queue or something ).

We have a application, which reads of JMS and does some database transactions, all as part of one XA transaction..
If we find the message has some problems, we want to rollback the database,
But we don’t want the rollback off JMS to have us read the message again.

Do you read the messages in your code or using Message Driven Beans?
We had the same problem with MDBs and solved it by delegating the processing of the messages to a session bean with RequiresNew transactional attributes of the methods. Database updates and sending other JMS messages were rolled back and MDB could still choose to commit its JMS-read transaction
If you read the messages in your code, I would try wrap the reading into another transaction, which can be commited/rolled back independently from the "main" one.

Some JMS providers have this functionality. WebLogic does it and so does MQ Series. Not sure about others. And even if they don't it's not that hard to roll your own. It just takes a bit of thinking while your doing the design to make sure that there are no loopholes whereby you could miss a message because of runtime exceptions you didn't allow for or something like that.

Is there a way to rollback a JMS transaction, causing the JMS provider to move the message to another queue ( Like a dead letter queue or something ).We have a application, which reads of JMS and does some database transactions, all as part of one XA transaction..If we find the message has some problems, we want to rollback the database,But we don’t want the rollback off JMS to have us read the message again.

The JMS spec way is to use a transacted session and use session.rollback(). If you use a JCA container (such as an EJB/MDB container or a Spring based JCA container) you can let the container do all of this work for you.

As a message is rolled back it will be redelivered. Most good JMS providers, such as ActiveMQ will have a configurable maximum redelivery count - on which point it will be consumed from the queue and sent to a dead letter queue.

This allows you to re-try messages due to, say, database deadlocks a fixed number of times then if that fails (due to a bad message) the message is put on a dead letter queue. This is all automatically done for you by your JMS provider - you just need to force the rollback().

James
LogicBlaze

Is there a way to rollback a JMS transaction, causing the JMS provider to move the message to another queue ( Like a dead letter queue or something ).

We have a application, which reads of JMS and does some database transactions, all as part of one XA transaction..
If we find the message has some problems, we want to rollback the database,
But we don’t want the rollback off JMS to have us read the message again.

Did you find a solution to this ? I'm currently using HornetQ with JBoss 5.1.0 and I'm trying to do something similar....I read messages with a MDB ... do some EJB calls which work something with a database. If the operations with the database fail and rollback occurs on the DB I don't want the JMS message to be rolledback as well ... I just want it to be acknowledge .