One Star

tMomInput: How to force a commit after each message is read

Hello,
TOS 3.2.0. tMomInput is working as designed. I need to force a "commit" after each message when accessing a specific MQ Series queue.
Is this a new feature request, or is there a way to force this in the current version that I am not seeing?
Thank you
Wayne
2 REPLIES
Community Manager

Re: tMomInput: How to force a commit after each message is read

Hello
I need to force a "commit" after each message when accessing a specific MQ Series queue.

What do you mean 'force a commit'?
Best regards

shong
----------------------------------------------------------
Talend | Data Agility for Modern Business
One Star

Re: tMomInput: How to force a commit after each message is read

When I build a Talend job that listens on the queue (queue listener), it appears that I need to force a ?commit? after each message that I pull in order to ensure that the message stays pulled. The ?commit? tells the queue manager that the message has been pulled and processed successfully. Without the "commit", the messages will roll back into the queue when the job ends.
This behavior depends on exactly how the queue is configured. In this case, I do not control the configuration of the queue. The IBM docs are pretty clear on what needs to happen.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzaw.doc/uj10990_....
On that page,
WebSphere MQ
|-Using Java
|- Websphere MQ Base Java API Reference
|- Package com.ibm.mq
|- MQ QueueManager
|- Methods
|- Commit

An easy implementation might be to add a check box to the Talend UI. If the box is checked,
Generate this line of code:
qMgrtMomInput_2.commit;
right after
String msg_tMomInput_2 = inMessagetMomInput_2.readString(inMessagetMomInput_2.getMessageLength());
The effect is that each read will be "committed" as it is read.
The commit is necessary because earlier in the code we see this:
gmotMomInput_2.options = gmotMomInput_2.options + com.ibm.mq.MQC.MQGMO_SYNCPOINT
By setting this option, the connection to the queue manager is enlisting in a synchronized transaction. SYNCPOINT is the right thing to do. We just need the option to force a "commit" so that the messages do not roll back.