| Author |
Message
|
| narendra |
 Posted: Fri Feb 07, 2003 1:24 pm Post subject: Propagate problem |
 |
|
Apprentice
Joined: 04 Jun 2002
Posts: 26
|
I a have a message flow to select large amount of data and break up each rown into XML message and propagate.
I have problem in selecting and propagating large amount of data.
It rolls back everything at the end with some database error.
Can I commint the each message after propaget.
Regards
Narendra |
|
| Back to top |
|
 |
| lillo |
| Posted: Mon Feb 10, 2003 1:00 am Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
The following lines are from the latest WMQI redbook(Developing solutions in WebSphere MQ Integrator, page 123):
| Quote: |
Remember that the Unit-Of-Work (UOW) is still coordinated by the input node.
So, all output messages are only committed after they are all successfully put
into their destination queues. If a failure occurs during the message flow
processing, all messages already in the output queues are rolled back. |
Cheers
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| kirani |
| Posted: Sat Feb 15, 2003 11:40 am Post subject: Re: Propagate problem |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| narendra wrote: |
Can I commint the each message after propaget.
|
Yes, you can! Try setting the Transaction Mode to 'No' in your MQOutput node.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| Yanghui |
| Posted: Mon Jul 21, 2003 8:16 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi,
What I want to achieve here is the opposite, either all propagate successful or none. I tried to set TransactionMode of all MQInput and MQOutput nodes and also DestinationData ones to Yes. All my messages are persistent. However, I just can't make this work. Those successful propagated message always show up on queue despite of those roll-back ones.
What do I miss of using PROPAGATE function here for making everything under transaction control?
Thanks in advance for your advice.
-Yanghui |
|
| Back to top |
|
|
| kirani |
| Posted: Mon Jul 21, 2003 8:28 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
To achieve this please make sure your message flow path ends with a Throw node in the Catch terminal of MQInput node. Don't forget to attach some kind of failure processing logic to Failure terminal of MQInput node.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Jul 22, 2003 8:59 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
If you have ANY kind of error handling implemented in the flow, other than wiring the Failure terminal of the Input node, then YOU are responsible for all Roll back functions in the flow.
If a Propogate is used, this is kinda difficult, because MQ has already sent these messages.
So, to make an all or nothing approach, only wire the Failure on the Input node for your error handling.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Jul 22, 2003 11:54 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
My last post was a little over-simplistic. Here's a better breakdown of how tansactional control is implemented:
Transaction mode = yes
Recovery is attempted in this sequence:
a) Failing node’s failure terminal
b) Previous catch terminal
c) Message returned to input queue, re-read, & processing retried. (Repeated until backout threshold exceeded)
d) MQInput node’s failure terminal
e) Input queue’s backout queue
f) Local queue manager’s dead-letter queue
g) Message flow loops until it can write the message to the dead-letter queue.
It’s only at c that uncommitted messages and database updates are rolled back.
So from the above, you can see that if the message is propagated via either a or b, then the message flow is considered to be SUCCESSFUL in a Transactional view. No messages, or database updates will be rolled back.
Also, it’s the message as input to the node where the ‘failure’ or ‘catch’ is wired that is the message propagated. I believe that the LocalEnvironment is rolled back to this point as well, which means if you want data to be available in the ‘error path’, then it needs to be stored in Environment.
BTW The catch terminal referenced in b can be the Input Node’s.
Transaction mode = no
Recovery is attempted in this sequence:
a) Failing node’s failure terminal
b) Previous catch terminal
If neither is connected, message is lost!
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Yanghui |
| Posted: Thu Jul 31, 2003 1:29 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi,
Sorry for late reply. I just got chance to prove that Kirani's method works.
Thank you for all your help.
Regards
-Yanghui |
|
| Back to top |
|
|
|
|
