| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Unit of Work (UOW) and multiple messages. |
« View previous topic :: View next topic » |
| Author |
Message
|
| Cogito-Ergo-Sum |
 Posted: Mon May 23, 2011 4:17 am Post subject: Unit of Work (UOW) and multiple messages. |
 |
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
As I have understood, WMB schedules a transaction for every incoming message. For example, in case of a FileInput node, for every input record, a transaction is scheduled and thus, every input record will have it's own Unit Of Work (UOW). But, now suppose, I have a user-defined node (UDN) that reads the same input file whose name was provided as input to this UDN. Would the input records from the file be now in separate UOWs ? I would think not; they are in the same UOW which was initiated when the file name was provided to this UDN. If this is true, then can the UDN be developed such that, every input record will have it's own Unit Of Work (UOW) ? One could possibly make the target of this UDN a MQ queue and, from there onwards, in another message flow, different UOWs would begin.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon May 23, 2011 4:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I think you're missing the distinctions between Input user-defined nodes and Message Processing user-defined nodes? |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Mon May 23, 2011 6:29 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
Well, the user-defined nodes were for illustration only.
Suppose, in the above question, the user-defined node is replaced with a Compute node which simply n-plicates (duplicate, triplicate and so on  ) the incoming message. Then, as above, would the n-plicated input records be now in separate UOWs ? I would think not; they are in the same UOW which was initiated when the input arrived at the Compute node. If this is true, then can the Compute node be instructed such that, every n-plicated record will have it's own Unit Of Work (UOW) ?
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 23, 2011 6:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You can use a Collector node to assemble a group of messages - either from the same source or different sources - into a single transaction. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Mon May 23, 2011 6:58 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
| mqjeff wrote: |
| You can use a Collector node to assemble a group of messages - either from the same source or different sources - into a single transaction. |
But, I am thinking, even without the Collector node, the multiple messages (from a Compute, etc. node) are already in the same transaction that initiated the message flow. No ?
If they are in the same transaction, then can a Compute (for example), node be instructed that, each of the n-plicated record will have it's own transaction ? I am guessing the answer would be no; as I do not think, I found documentation to the contrary.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 23, 2011 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Cogito-Ergo-Sum wrote: |
| If they are in the same transaction, then can a Compute (for example), node be instructed that, each of the n-plicated record will have it's own transaction ? |
If this was possible (and I don't believe it is) where in this design would you want the message rolled back to if the new UoW failed? The original input message has been read in the first UoW (which hasn't failed & is presumably committed at this point) so the new message could only roll back to the Compute node. Where would it go from there? What would be the poisition is some of the propogated messages worked but others didn't? All of these new UoWs would then (presumably) committ or fail according to their lights. How would you guarantee integrity, resolve the issues and re-present the correct messages to the correct route?
The possibilities for tying yourself in knots seem quite high if you could get this working. The possibilities for some of these knots to form a noose don't seem that long..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 23, 2011 7:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yes, all messages sent out of a compute node are still in the same transaction as the input node, at least for purposes of message rollback.
No, there is no mechansim that I am aware of in ESQL or other transformation interface to create a separate Message Flow transaction.
You can use the various Get/Read/Request nodes to augment a control message with a specific number of business records - for example you could write a flow that acted as an MQ trigger monitor and read an MQ initiation message, and then use an MQGet node to read 10 or 100 or etc. messages from a different queue and then process them in a unit of work.
So there are various scenarios where you can control how big your unit of work is. Some people prefer larger units, some people prefer smaller units. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Mon May 23, 2011 9:34 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
Thank you, mqjeff and Vitor ! I hear exactly what I wanted to hear.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
