| Author |
Message
|
| jamesyu |
 Posted: Fri Nov 16, 2007 7:35 am Post subject: "Commit by message group" doesn't seem to be worki |
 |
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
I've developed a very simple flow to try message grouping.
My MQInput node has the following properties set:
1. Order mode = By Queue Order
2. Logical order = checked
3. Commit by message group = checked
I use RFHUTIL to create a group with 3 messages with seq # 1, 2 and 3. The message with seq # 3 is also the last message in group.
In ESQL, I programmatically forced the second message always failed with parser exception returned, and the messages 1 & 3 are good to go.
After testing, the first and second messages went to my backout queue, but the last message with seq # 3 was commited successfully to my target output queue.
What I am expecting from the setting of "Commit by message group" is the whole group either commited or rolled back. What am I missing?
Thanks,
James |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Nov 16, 2007 12:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
what you are missing is that you need a (probably shared) flag that you need to clear at the beginning of each group. Set the flag whenever you fail a message. For the remainder of the messages in the group there is no need to process them. You already had a fail in the group and can throw and exception... so the whole group will be rolled back... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Nov 16, 2007 1:38 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
What version of the Broker are you using. I seem to remember that the behaviour of how Groups were handled changed at some point.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jamesyu |
| Posted: Mon Nov 19, 2007 6:51 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
| EddieA wrote: |
What version of the Broker are you using. I seem to remember that the behaviour of how Groups were handled changed at some point.
Cheers, |
Broker runtime: 6005 (returned by mqsiervice -v)
Toolkit: 6.0.2 with the ifix 009
Please advise. |
|
| Back to top |
|
|
| jamesyu |
| Posted: Mon Nov 19, 2007 6:56 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
| fjb_saper wrote: |
| what you are missing is that you need a (probably shared) flag that you need to clear at the beginning of each group. Set the flag whenever you fail a message. For the remainder of the messages in the group there is no need to process them. You already had a fail in the group and can throw and exception... so the whole group will be rolled back... |
Isn't this supposed to be handled by settings on MQInput node only? At least this what the documenation on the usage of MQInput node describes about how to handle message groups.
What you are suggesting is to programmatically write some code to handle this, isn't it? Is this the way supposed to be?
Thanks,
James |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Nov 19, 2007 1:47 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The MQ Input node is going to start a new transaction for each message in the group, when it starts an instance of the message flow to process that message.
Each instance of the message flow is entirely separate from every other instance.
If you need to process all of the messages in a group in a combined transactions - then a) maybe you should be using segmentation rather than grouping, OR b) if you can wait until you've migrated to v6.1, then you can use the Collector node to assist with this, OR c) you need to write your flow to do the group processing to ensure that you get the behavior you want.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jamesyu |
| Posted: Tue Nov 20, 2007 6:49 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
In my case, I set "Addtional Instances" to 0 in my bar file, so it's just one thread.
I really wish someone could read the documentation on the MQInput node about the usage of "Commit by message group" and let me know how to use it in flows and why it doesn't behave the way it's supposed to be.
All what I want is that my group of messages is either submitted or rolled back together. Not part of the group rolled back, and another part of the same group commited. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 20, 2007 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried looking at it differently...ie all messages in group and logical message?
You should only get 1 message back and then you can slice it for further processing...but make sure the XML stays valid at group level... and it might get too big for convienient processing....
I'm not sure if I am confusing the behavior of the input node with group or with split flag set.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jamesyu |
| Posted: Wed Nov 28, 2007 12:10 pm Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
Found this from WMB Info Center and it explains why:
WebSphere MQ supports message groups. You can specify that a message belongs to a group and its processing is then completed with reference to the other messages in the group (that is, either all messages are committed or all messages are rolled back). When you send grouped messages to a broker, this condition is upheld if you have configured the message flow correctly, and errors do not occur during group message processing.
To configure the message flow to handle grouped messages correctly, follow the actions described in the MQInput node. However, correct processing of the message group cannot be guaranteed if an error occurs while one of the messages is being processed.
If you have configured the MQInput node as described, under normal circumstances all messages in the group are processed in a single unit of work which is committed when the last message in the group has been successfully processed. However, if an error occurs before the last message in the group is processed, the unit of work that includes the messages up to and including the message that generates the error is subject to the error handling defined by the rules documented here, which might result in the unit of work being backed out.
However, any of the remaining messages within the group might be successfully read and processed by the message flow, and therefore are handled and committed in a new unit of work. A commit is issued when the last message is encountered and processed. Therefore if an error occurs within a group, but not on the first or last message, it is possible that part of the group is backed out and another part committed.
If your message processing requirements demand that this situation is handled in a particular way, you must provide additional error handling to handle errors within message groups. For example, you could record the failure of the message group within a database, and include a check on the database when you retrieve each message, forcing a rollback if the current group has already encountered an error. This would ensure that the whole group of messages is backed out and not processed unless all are successful.
Thanks,
James |
|
| Back to top |
|
|
|
|
