| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS rollback issue, can't see message on backout queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| chrisgclark |
 Posted: Fri Jul 10, 2009 3:38 am Post subject: JMS rollback issue, can't see message on backout queue |
 |
|
Apprentice
Joined: 26 Mar 2009
Posts: 35
|
Hi,
I have a JMS program which listens & reads a message off a queue and throws an exception if no 'replyto' queue is set. The exception block issues a JMS session rollback. The problem is that the message then appears on the request.Backout queue (i.e. queue depth increases), but I can not browse or read this message from the backout queue (no message visible using MQ Explorer and RFHUtil). Its like something has a lock on this message.
This backed out message remains on the backout queue, unviewable, until I close my JMS program. When I close the program the message then moves from the backout queue to the initial request queue and is viewable again.
It is like the backed out message is uncommited. I have tried issuing a commit after the rollback but no joy. I have also tried closing the session/connection factory after the rollback, but this causes the message to move from the backout queue to the request queue.
Any ideas?
Thanks,
Chris |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jul 10, 2009 4:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You're trying to back the message out in the same session as the one you used to get it from the request queue.
And, yes, your message on the backout queue is uncommitted. The removal from the request queue is uncommitted, and the put to the backout queue is also uncommitted. When you close the session, both of these transactions roll back.
You need to commit the removal from the request queue, and put the message to the backout queue from a non-transacted session. |
|
| Back to top |
|
|
| chrisgclark |
| Posted: Fri Jul 10, 2009 7:39 am Post subject: |
|
|
Apprentice
Joined: 26 Mar 2009
Posts: 35
|
mqjeff, many thanks. You solved the problem!
We are now handling committing the original get and putting the backout message as separate transations, in different sessions.
We are now doing the following:
- creating session1
- getting message
- try process message
if (reply problems, e.g. replyTo not set)
- create session2
- put message on backout queue
- commit session2
- end session2
if (message delivered to replyTo queue or Backout msg successful)
- commit session1
end session1 |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
