ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Transaction Mode Automatic and Non Persistent messages

Post new topic  Reply to topic
 Transaction Mode Automatic and Non Persistent messages « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Tue Nov 13, 2007 11:59 am    Post subject: Transaction Mode Automatic and Non Persistent messages Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Is my understanding correct?


If the message flow encounters a problem, it would normally roll the message back to the MQInput Node which would then roll the message back to the Input Queue (after trying the Catch terminal first). The flow would then get the message again and check the backout count of the message, now 1. If the message's backout count is > than the Input Queue's backout count (typically 0), the MQInput node calls the Failure Terminal if wired and puts it to the Fail queue. If the Failure Terminal is not wired the flow checks the Input queue's backout q attribute and puts it there. If there is no backout q specified and no failure terminal wired it puts it to the Broker's DLQ.

HOWEVER, this all assumes the flow can rollback the message to the Input q to start that whole process. If the transaction mode is Auto, that means no syncpoint if the message is not persistent. If no synpoint, the message can't be rolled back to the Input queue, so the flow just throws it away at this point (because the message is not persistent AND you told it you don't care by setting the Mode to Automatic)

or ?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Nov 13, 2007 12:10 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Um.

Sounds about right... But it's been a while since I've reviewed it in detail.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Nov 13, 2007 12:25 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

If a flow's MQInput node has Transaction Mode set to Yes which means look at the message's persistence to determine if it should use syncpoint, how does the flow know to use syncpoint or not going into the MQGET if it hasn't seen the message yet?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Nov 13, 2007 12:29 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Transaction Mode = YES means "Use a transaction, always".

Transaction Mode "No" means use "Never use a transaction".

I don't think it's ever been documented or explained how the MQInput node handles "transaction mode = Automatic".

If *I* were coding it, I'd either a) browse the queue first, and then re-get based on the header, or b) always do a syncpoint, and issue an immediate commit if it's not persistent.

Likely the people who coded the MQInput node did something much smarter.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
mqmatt
PostPosted: Wed Nov 14, 2007 7:10 am    Post subject: Reply with quote

Grand Master

Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK

The queue manager knows if the message being retrieved is persistent. When transaction mode is automatic, the node asks the queue manager to get the message under syncpoint if it is persistent, and not if it isn't. (It's in the get message options.)
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Nov 14, 2007 8:06 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Got it, thanks.

So if a flow's MQInput Node has its Transaction Mode set to No, or its set to Automatic and it deals exclusibvly with non persistent messages, its pointless to connect the failure terminal.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Nov 14, 2007 8:33 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

PeterPotkay wrote:
Got it, thanks.

So if a flow's MQInput Node has its Transaction Mode set to No, or its set to Automatic and it deals exclusibvly with non persistent messages, its pointless to connect the failure terminal.


I generally never connect the failure terminal. There's too many good reasons to let the MQInput node perform it's normal failure processing - including backout.

There's a redpiece/devWorks article somewhere called "BulletProofing Message Broker flows" or some such. Very informative.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
dkeister
PostPosted: Wed Nov 14, 2007 9:53 am    Post subject: Reply with quote

Disciple

Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York

Wow, finally I'm able to give back...

http://www.redbooks.ibm.com/redpapers/pdfs/redp4043.pdf
_________________
Dean Keister
Back to top
View user's profile Send private message Send e-mail Visit poster's website
PeterPotkay
PostPosted: Wed Nov 14, 2007 10:03 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

jefflowrey wrote:
I generally never connect the failure terminal. There's too many good reasons to let the MQInput node perform it's normal failure processing - including backout.

There's a redpiece/devWorks article somewhere called "BulletProofing Message Broker flows" or some such. Very informative.

If the MQInput node is going to backout the message to the Backout Q or to the Fail Q via the failure terminal, it accomplishes the same thing, right? You either take the time to wire the failure terminal or you take time to set the Input Q's Backout Q attribute.

The PDF is printing now!
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
dkeister
PostPosted: Wed Nov 14, 2007 10:07 am    Post subject: Reply with quote

Disciple

Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York

That is my understanding. I agree with Jeff in never wiring the failure terminal and trying to do something (even putting to a queue). I think you can get into a deadly embrace if there is a problem on that path (i.e. the message cannot be put to the queue for some reason)...
_________________
Dean Keister
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jefflowrey
PostPosted: Wed Nov 14, 2007 10:10 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

If you wire the failure terminal, then you're instructing the MQInput that you will handle everything.

Including database transactions...

I generally don't wire the failure terminal. It's just as easy (and there's more real information) to write to the Fail queue at the Catch terminal, and then rethrow or not, based on requirements.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Transaction Mode Automatic and Non Persistent messages
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.