| Author |
Message
|
| MrVMax |
 Posted: Wed Oct 03, 2018 4:28 am Post subject: Howto issue an explicit MQCMIT command inside a flow |
 |
|
Novice
Joined: 01 Aug 2013
Posts: 23
|
Hi all,
I've a requirement to issue a COMMIT on MQ inside a subflow that don't use any database but only Queues.
The ESQL command COMMIT is not supported, in a compute node the transaction property of COMMIT is supported only with the specification of an ODBC source name is there any way to issue a MQCMIT ?
If I don't find a way i must raise the uncommitted message limit of the MQ at a level very hight and I feel not very confortable in doing this.
By the way what's a reasonable limit of uncommitted messages on some QMGR I use 100.000 without any trouble but in this case I should use a lot more. |
|
| Back to top |
|
 |
| abhi_thri |
| Posted: Wed Oct 03, 2018 4:40 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
hi...i think that is fairly straight forward to achieve, you just need to set the 'Transaction Mode' of the MQOutput node property to 'No' which takes it out of the parent transaction.
You haven't mentioned the scenario for which you want to do this, ideally it should be done for scenarios where you want to do something extra (eg:- logging the error details to a queue in the error subflow) |
|
| Back to top |
|
|
| MrVMax |
| Posted: Wed Oct 03, 2018 7:36 am Post subject: |
|
|
Novice
Joined: 01 Aug 2013
Posts: 23
|
Well ... I don't need to put some messages to a queue outside a transaction, but i need to commit a transaction.
As You said set the 'Transaction Mode' of the MQOutput node property to 'No' makes the put operation outside the current transaction that stills remain uncommitted.
I've a complex flow with some subflow; the main flow use MQINPUT node to read messages from the MAINCONTROL queue that is a control queue: the messages that will be on the queue are supposed to make the flow go trough the different subflows like start the one or another subflow.
Each subflow once "started" from main reads messages from it's own input queue SUB(x)INQ using MQGET node till it reads a particular sequence of bytes (called STOP SEQUENCE) at the end of a message.
Each subflow use the message it has received dividing the message itself into different row of a db table and from each row create a new message on the SUB(x)OUTQ.
The STOP SEQUENCE makes the subflow post a control message to the MAINCONTROL queue and return to the main flow that will go trough another subflow based on the control message received.
My need is to have a MQCMIT performed after the last put on the SUB(x)OUTQ. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 03, 2018 7:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MrVMax wrote: |
| Each subflow once "started" from main reads messages from it's own input queue SUB(x)INQ using MQGET node till it reads a particular sequence of bytes (called STOP SEQUENCE) at the end of a message. |
That is a horrible design and is a great way to run an execution group out of memory.
Both this problem and your commit problem will be solved (or at least easier) if you break these subflows out as actual flows. If you need to get back into the logic of your main flow, use one of the aggregation constructs to do that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| timber |
| Posted: Wed Oct 03, 2018 11:16 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
| I agree with Vitor. As a general rule, you should treat MQGet nodes like goto statements. They are sometimes the right option, but if you think you need one you should always think again. |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Thu Oct 04, 2018 12:21 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
| Agree with both the Gents that it is best to keep things simple where possible and people will thankyou for it... When coming up with designs it is always good to think about how easily it can be supported/maintained in the long run. |
|
| Back to top |
|
|
|
|
