Author |
Message
|
catshout |
Posted: Thu Oct 10, 2013 2:10 am Post subject: Sending 2 messages within one atomic transaction |
|
|
Acolyte
Joined: 15 May 2012 Posts: 57
|
Hi anybody,
I do have a given flow that sends multiple messages out. This is being triggered by PROPAGATE statements within a ESQL WHILE loop.
For each step are required to send 2 messages to different Q's within one atomic transaction. The flow input is set to "Transaction No".
I'm looking for any best practices to send either 2 messages out or none within this transaction. Is the BEGIN .. END around the PROPAGATES an appropriate way? Any other pitfalls?
Any hints are highly appreciated.
Best
- catshout |
|
Back to top |
|
 |
dogorsy |
Posted: Thu Oct 10, 2013 2:19 am Post subject: Re: Sending 2 messages within one atomic transaction |
|
|
Knight
Joined: 13 Mar 2013 Posts: 553 Location: Home Office
|
catshout wrote: |
Hi anybody,
I do have a given flow that sends multiple messages out. This is being triggered by PROPAGATE statements within a ESQL WHILE loop.
For each step are required to send 2 messages to different Q's within one atomic transaction. The flow input is set to "Transaction No".
I'm looking for any best practices to send either 2 messages out or none within this transaction. Is the BEGIN .. END around the PROPAGATES an appropriate way? Any other pitfalls?
Any hints are highly appreciated.
Best
- catshout |
If you read the ATOMIC section of the BEGIN, END statement you will find the answer.
so, that is my hint: read the documentation !! |
|
Back to top |
|
 |
Esa |
Posted: Thu Oct 10, 2013 2:45 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
BEGIN ATOMIC makes the enclosed code block atomic, meaning that only one thread can execute it at a given time.
But if you propagate messages to two MQOutput nodes within the atomic block, you still get two separate MQ transactions (with transaction property of the MQOutput nodes is set to 'No'.
So if you get an exception after the first message is sent, the transaction breaks.
Now, maybe your requirement is not correct. Why cannot you send all the messages within one MQ transaction? Let's assume that you manage to commit the message pairs separately. What happens if you get an exception after having sent a number of message pairs? If the message is retried, the already committed messages will be sent twice, unless you write some code that checks a log for sent messages to prevent it.
If you really need to send message pairs within their own transactions, concatenate each message pair in one message, send it to another queue outside transaction and make another flow separate the messages and send them within transaction. And send a reply back to the first flow so that it can continue.
Last edited by Esa on Thu Oct 10, 2013 2:49 am; edited 1 time in total |
|
Back to top |
|
 |
catshout |
Posted: Thu Oct 10, 2013 2:49 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012 Posts: 57
|
Code: |
If you read the ATOMIC section of the BEGIN, END statement you will find the answer. |
The documentation says:
If ATOMIC is specified, only one instance of a message flow (that is, one thread) is allowed to execute the statements of a specific BEGIN ATOMIC... END statement (identified by its schema and label).
This is the singleton principle in my mind but has nothing to do with transactions and sync points? |
|
Back to top |
|
 |
dogorsy |
Posted: Thu Oct 10, 2013 2:59 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013 Posts: 553 Location: Home Office
|
Esa wrote: |
But if you propagate messages to two MQOutput nodes within the atomic block, you still get two separate MQ transactions (with transaction property of the MQOutput nodes is set to 'No'.
|
WRONG. Maybe you should also read the documentation.
Quote: |
Do not nest BEGIN ATOMIC... END statements, either directly or indirectly, because this could lead to "deadly embraces". For this reason, do not use a PROPAGATE statement from within an atomic block. |
Last edited by dogorsy on Thu Oct 10, 2013 3:01 am; edited 1 time in total |
|
Back to top |
|
 |
dogorsy |
Posted: Thu Oct 10, 2013 3:00 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013 Posts: 553 Location: Home Office
|
catshout wrote: |
Code: |
If you read the ATOMIC section of the BEGIN, END statement you will find the answer. |
The documentation says:
If ATOMIC is specified, only one instance of a message flow (that is, one thread) is allowed to execute the statements of a specific BEGIN ATOMIC... END statement (identified by its schema and label).
This is the singleton principle in my mind but has nothing to do with transactions and sync points? |
The documentation also states very clearly:
Quote: |
Do not nest BEGIN ATOMIC... END statements, either directly or indirectly, because this could lead to "deadly embraces". For this reason, do not use a PROPAGATE statement from within an atomic block. |
|
|
Back to top |
|
 |
Esa |
Posted: Thu Oct 10, 2013 3:14 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
dogorsy wrote: |
Esa wrote: |
But if you propagate messages to two MQOutput nodes within the atomic block, you still get two separate MQ transactions (with transaction property of the MQOutput nodes is set to 'No'.
|
WRONG. Maybe you should also read the documentation.
Quote: |
Do not nest BEGIN ATOMIC... END statements, either directly or indirectly, because this could lead to "deadly embraces". For this reason, do not use a PROPAGATE statement from within an atomic block. |
|
dogorsy, this has nothing to do with MQ transactions, but nesting atomic blocks. If you propagate from within an atomic block and some downstream node runs another atomic block, you get a lock. That's what it says. |
|
Back to top |
|
 |
dogorsy |
Posted: Thu Oct 10, 2013 3:23 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013 Posts: 553 Location: Home Office
|
Esa wrote: |
dogorsy wrote: |
Esa wrote: |
But if you propagate messages to two MQOutput nodes within the atomic block, you still get two separate MQ transactions (with transaction property of the MQOutput nodes is set to 'No'.
|
WRONG. Maybe you should also read the documentation.
Quote: |
Do not nest BEGIN ATOMIC... END statements, either directly or indirectly, because this could lead to "deadly embraces". For this reason, do not use a PROPAGATE statement from within an atomic block. |
|
dogorsy, this has nothing to do with MQ transactions, but nesting atomic blocks. If you propagate from within an atomic block and some downstream node runs another atomic block, you get a lock. That's what it says. |
I think what it says is: do not use a PROPAGATE statement from within an atomic block.
And in fact, if I remember well, if you try to do a propagate from within an atomic block you will get a runtime error.
Maybe I cannot read properly, but I don't see anything about a downstream node doing another atomic block, etc. Can you please point me out to that part of the documentation? |
|
Back to top |
|
 |
Esa |
Posted: Thu Oct 10, 2013 3:29 am Post subject: Re: Sending 2 messages within one atomic transaction |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
dogorsy wrote: |
If you read the ATOMIC section of the BEGIN, END statement you will find the answer.
so, that is my hint: read the documentation !! |
dogorsy wrote: |
I think what it says is: do not use a PROPAGATE statement from within an atomic block.
And in fact, if I remember well, if you try to do a propagate from within an atomic block you will get a runtime error. |
This way or that, I think the conclusion is that BEGIN ATOMIC is not the answer to OP's problem. |
|
Back to top |
|
 |
dogorsy |
Posted: Thu Oct 10, 2013 3:34 am Post subject: Re: Sending 2 messages within one atomic transaction |
|
|
Knight
Joined: 13 Mar 2013 Posts: 553 Location: Home Office
|
Esa wrote: |
dogorsy wrote: |
If you read the ATOMIC section of the BEGIN, END statement you will find the answer.
so, that is my hint: read the documentation !! |
dogorsy wrote: |
I think what it says is: do not use a PROPAGATE statement from within an atomic block.
And in fact, if I remember well, if you try to do a propagate from within an atomic block you will get a runtime error. |
This way or that, I think the conclusion is that BEGIN ATOMIC is not the answer to OP's problem. |
whether you think that or not, "DO NOT USE PROPAGATE STATEMENT from within an atomic block" is clear enough, wouldn't you agree ?!!! |
|
Back to top |
|
 |
catshout |
Posted: Thu Oct 10, 2013 4:11 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012 Posts: 57
|
Conclusion at this point:
BEGIN ATOMIC ... END; with PROPAGATEs in it will cause an exception. And, it has nothing to to with transactions.
My question again:
The MQ Input Node starting the flow must be set to Transaction "No" (given constraint). Both downstream MQ Output Nodes are set to Transaction "Yes". Both PROPAGATEs to these MQ Output Nodes are running within a BEGIN ... END; block (without ATOMIC). But this still seems to produce the case that one message is being sent and the other not.
How to ensure that either both messages are sent or none? |
|
Back to top |
|
 |
Esa |
Posted: Thu Oct 10, 2013 4:15 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
Esa wrote: |
If you really need to send message pairs within their own transactions, concatenate each message pair in one message, send it to another queue outside transaction and make another flow separate the messages and send them within transaction. And send a reply back to the first flow so that it can continue. |
And send a negative reply if the second flow catches an exception. Use MQGet node with proper correlation and timeout settings to read the replies. |
|
Back to top |
|
 |
|