Threads and Jms Transaction

Question

I am stuck in the following scenario.Please advice me on this

There is an inbound Queue There is an Main thread running(We are not using JMS Listener ) and picking a message from the queue and process the message and start another sub thread to process again.

Now the problem is How can i handle the transaction in the main thread and sub thread as well. which mean when i process the message in main thread say some Data Base access error occurs so i want to rollback the message back to inbound Queue. and if the same failure occurs in sub thread which was created by the main thread, the retrieved message should rollback to inbound Queue.

I have walked through the JMS Spring Reference ,But they are demarcate the transaction only to JMS Listeners

So How can i apply the transaction concept in my scenario

Please advice me ,If you have any sample program please share with me .That would be better to understand your concepts

Answer 1

If I understand well, you have one main thread that fetches the messages, and spawn other threads for their processing.

JMS supports having several listeners which fetch message concurrently in a transacted way. That's actually one of the benefits of JMS: you can have transacted, concurrent message delivery.

So I suggest you use a thread pool, where each thread has its own listener. The thread fetches a message and process it form within one transaction, and then loops. This way if the processing fails, the message stays in the queue. Each thread has a listener so you don't need the main thread any longer.

Otherwise goolge for Message Driven Bean, and see if Spring support some kind of similar concept.

Answer 2

I think you are in difficult territory here. Having two threads working in the same transaction seems to me to be fraught with race conditions and other dangers - in fact I'm not even sure it is possible. The JTA transaction API that I'm familiar with uses one-to-one mappings from threads to transactions.

Why can you not instead have a pool of threads each taking the message from the queue and doing all the work. Then there's no need for spawing a new thread after taking the message. You get just as good parallelism and greater simplicity.

You then find that you've effectively reinvented the standard Java approaches. So why not just use an MDB?