Author |
Message
|
PeterPotkay |
Posted: Tue Nov 13, 2007 11:59 am Post subject: Transaction Mode Automatic and Non Persistent messages |
|
|
 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 |
|
 |
jefflowrey |
Posted: Tue Nov 13, 2007 12:10 pm Post subject: |
|
|
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 |
|
 |
PeterPotkay |
Posted: Tue Nov 13, 2007 12:25 pm Post subject: |
|
|
 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 |
|
 |
jefflowrey |
Posted: Tue Nov 13, 2007 12:29 pm Post subject: |
|
|
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 |
|
 |
mqmatt |
Posted: Wed Nov 14, 2007 7:10 am Post subject: |
|
|
 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 |
|
 |
PeterPotkay |
Posted: Wed Nov 14, 2007 8:06 am Post subject: |
|
|
 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 |
|
 |
jefflowrey |
Posted: Wed Nov 14, 2007 8:33 am Post subject: |
|
|
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 |
|
 |
dkeister |
Posted: Wed Nov 14, 2007 9:53 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002 Posts: 184 Location: Purchase, New York
|
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Nov 14, 2007 10:03 am Post subject: |
|
|
 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 |
|
 |
dkeister |
Posted: Wed Nov 14, 2007 10:07 am Post subject: |
|
|
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 |
|
 |
jefflowrey |
Posted: Wed Nov 14, 2007 10:10 am Post subject: |
|
|
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 |
|
 |
|