| Author |
Message
|
| madi |
 Posted: Mon May 01, 2006 7:30 am Post subject: Transaction |
 |
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
Hi All
I am trying to get a message flow into one transaction, I mean i want the DB update to be committed on if I can out the message into a different queue and vice versa.
I have set the transaction setting on the MQOutput nodes to Yes and Automatic on the DB nodes.
i get a message and I write to a queue and a database simultaneously. The requirement is that if one fails the other also must be backedout.
but this is not happening with the setting above, do i need to put the DB node in Commit??
plz help
madi
Last edited by madi on Wed May 03, 2006 1:16 pm; edited 2 times in total |
|
| Back to top |
|
 |
| sirsi |
| Posted: Mon May 01, 2006 8:32 am Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
| Are u handling any errors? Is your catch terminal of Input node connected? |
|
| Back to top |
|
|
| madi |
| Posted: Mon May 01, 2006 8:47 am Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
yeah i have an error flow to handle errors..
so you think the error flow is also considered in the transaction and since the error flow completes fully, the transaction if commited??
--madi |
|
| Back to top |
|
|
| sirsi |
| Posted: Mon May 01, 2006 8:55 am Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
|
| Back to top |
|
|
| madi |
| Posted: Mon May 01, 2006 10:24 am Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
so im better off using a flow order node?? right, i mean i have this error flow which takes in all the exceptions that occur in the flows and creates an alert.
So my only option of making stuff transactional is to implement a flow order.
would that work though, i mean if the first flow goes fine but something happens after the second output from the flow order node, the first flow is already executed right??
--madi |
|
| Back to top |
|
|
| sirsi |
| Posted: Mon May 01, 2006 11:56 am Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
|
| Back to top |
|
|
| madi |
| Posted: Mon May 01, 2006 12:30 pm Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
my error handler pretty does the same thing .. but the inclusion of the ErrorFlag and the floworder node might do the trick. anyway thanks for the find!!
--madi |
|
| Back to top |
|
|
| sirsi |
| Posted: Mon May 01, 2006 2:47 pm Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
Hi madi,
If your problem has been solved then please prefix your post name with "[SOLVED]".
Thanks |
|
| Back to top |
|
|
| madi |
| Posted: Wed May 03, 2006 1:16 pm Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
so if the message flow ends with an exception wont the message be placed in the error or the dead letter queue??
i want the transaction logic to be implemented but we dont want the xml to go to the err queue
for example
i get a message with 5 repeated tags which i need to write to the database
and an exception is thrown at the 3rd tag, i want to roll back all the changes done till then but still be able to capture the message and create an alert so it does not go to the error queue
is that possible
this is what im doing right now
i catch the exception at the MQInput Catch terminal and checking the backout count and if it is less than 2 i throw an exception so that the control returns to the MQInput and the backout logic is implemented ......
as soon as the backCount reaches its threshold i create an alert xml and send to an app to create a ticket
i include the xml as a CData tag in the alert xml
will this be considered as a successful transaction then because it did not end with an exception
how can i make the database changes roll back??
--madi |
|
| Back to top |
|
|
| sirsi |
| Posted: Wed May 03, 2006 3:02 pm Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
i dindnt get the reason for checking backout count less than 2...
What you can do is you can raise the exception after putting the alert message in the desired queue ( the transaction setting should be NO for this Output Node ). This will rollback all the changes expect the putting of alert message on the desired queue. |
|
| Back to top |
|
|
| madi |
| Posted: Wed May 03, 2006 6:11 pm Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
Yeah, that is what I am doing right now.
But if I raise the exception after the alert is put on the queue, the original message would go to the ERR queue right??
but I dont want this to happen because the alert xml already has the original message as CData and we dont want the same thing in the ERR queue!!
Im checking the backout count because we want the flow to try 3 times to process the message before we raise an alert
--madi |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 03, 2006 7:51 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Wouldn't it be a lot simpler to set the backout count to 3, and deploy a flow to the ERR queue that would raise the alert?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| madi |
| Posted: Thu May 04, 2006 6:09 am Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
well it would be a lot simpler, i'll give you that 
but if something happens in the flow to the ERR queue, where would the messages go, so we should have another error queue (like a 'really dead letter queue'  )!!!
what we are trying to do is raise an alert through an app if we can handle the exceptions occurring in the flows
we also raise an alert if something goes into the error queue but then we want to limit these to malformed messages or unparsable messages etc
this is our plan (and part of it because the MQ infrastructure guys dont want to give us visibility to the production ERR queue)
--madi |
|
| Back to top |
|
|
| sirsi |
| Posted: Thu May 04, 2006 7:44 am Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
how about trying this?
After backout count has reached 3. Send alert message to desired queue.. give PASSTHRU(ROLLBACK) and then dont rise an exception. Not sure whether this works out for you. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu May 04, 2006 8:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| madi wrote: |
well it would be a lot simpler, i'll give you that
but if something happens in the flow to the ERR queue, where would the messages go, so we should have another error queue (like a 'really dead letter queue' )!!! |
I think you mean "SYSTEM.DEAD.LETTER.QUEUE". 
Among other things, if you allow messages that fail in your error handler to go there, then you will be adding burden to the MQ administrators team, who don't want you to have visibility to the production err queue.
To meet your requirements, I would handle it exactly as I've said - allow rollback to retry three times - if inside the flow I get an error I know I can handle, handle it and raise an alert. Otherwise rollback to the backout queue and raise an alert there if it's the right thing to raise.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
