| Author |
Message
|
| novice |
 Posted: Mon Dec 19, 2005 10:45 am Post subject: Propagate and Transaction Question |
 |
|
Apprentice
Joined: 20 Jun 2005
Posts: 37
|
I've one input message. From this message I generate x output messages with the esql propagate statement.
In one case the flow is terminated with an MQ Output Node and in the other case the flow is terminated with a DB (Insert) Node.
How is in both cases the transaction defined?
How can I influence the tranaction?
Thanks! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Dec 19, 2005 11:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In both cases, the transaction is completely defined by the combination of the transaction settings on all nodes that are invovled.
So if your flow propagates to the MQOutput node and the DBInsert node, then the transaction is completely defined by the transaction properties of all three nodes.
This is also the answer to your second question.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| novice |
| Posted: Mon Dec 19, 2005 11:30 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2005
Posts: 37
|
In the case of the DBInsert Node I can choose the transaction to be Automatic or Commit.
If it's Automatic so every insert per propagated output message is rolled back if an exception occurs.
If it's Commit every insert per propagated output message is commited immediately.
So far ok.
Is there a way to do the same thing in case of an MQOutput node. The tansaction is configurable. It can be Automatic (derived from MQInput Node), Yes or No.
I propagete x messages from one input message and on the nth output message an exception occurs. The messages 1 to n-1 have been already commited. How can I roll them back? |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Mon Dec 19, 2005 9:37 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi novice,
I dont think you can rol back the messages that have gone out from the output.
The flow is not holding all the messages you want to propagate, and then in one burst sending then all....it does it one by one as they come.
You'll have to figure out your own logic for this.
Regards. |
|
| Back to top |
|
|
| Ramphart |
| Posted: Mon Dec 19, 2005 10:56 pm Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| elvis_gn wrote: |
Hi novice,
I dont think you can rol back the messages that have gone out from the output.
The flow is not holding all the messages you want to propagate, and then in one burst sending then all....it does it one by one as they come.
|
This is incorrect. You can set your flow to roll back all the written messages. One thing you can consider is to write out group messages when you propagate. This won't solve the problem completely though. I think you are breaking your transaction somewhere within your flow. Maybe you handling errors on your input nodes catch terminal and breaking the transaction. Bottom line though, if you make sure that you don't break your transaction anywhere in your flow (or subflow) then you'll get all you propagated messages to roll back.
Maybe you should post the layout of your flow here indicating where you manipulate transaction settings
_________________
Applications Architect |
|
| Back to top |
|
|
| meenakshi |
| Posted: Tue Dec 20, 2005 3:01 am Post subject: |
|
|
Novice
Joined: 15 Jun 2005
Posts: 11
Location: India
|
Hi,
It is possible for you to rollback your entire transaction so far.
1) Wire the failure terminal of the input node to a failure queue. The original message is put to the failure queue and all the transactions (MQ and DB2) are rolled back. For this ensure that the node are using transactions.
2) If you are handling an exception on a catch node, then the transaction is considered to be successful and all updates prior to the exception are committed. You can use a throw node in this case to throw the exception back, so that the transactions are not comitted.
3) If you do not want to do any processing at all, a simple option would be to configure the backout queue and backout threshold on the input queue. In case of any exception the message would be moved to the backout queue after the backout count exceeds the backout threshold. Again ensure that you are using transactions where required.
I hope this helps you. |
|
| Back to top |
|
|
|
|
