| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| DatabaseInput node failure processing info |
« View previous topic :: View next topic » |
| Author |
Message
|
| NealM |
 Posted: Thu Oct 08, 2015 8:51 am Post subject: DatabaseInput node failure processing info |
 |
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
After I ran into some problems with first use of the DBI node, and didn't find any resolution in IBM's knowledge center nor in searches here, I opened a PMR. IBM acknowledges that failure processing info for that node is currently deficient and will be updated at some point in the future. The L2 did post a detailed Q&A session that IBM had with an earlier practitioner on a PMR, which will be a base for the future documentation improvements. Not being sure when that will happen, I decided to post the very useful info here, in 5 short parts.
| Quote: |
1. Retry Logic on DataBaseInput node. Does the Retry threshold apply to the Short and Short/Long retry or just the Short retry?
The 3 documented retry options after a failure are:
- Failure
- Short retry
- Short and long retry
It would have been clearer if the options had been worded:
- Failure
- Short retry then failure
- Short retry then long continuous retry
After a message that has been sent down the Out terminal of the DatabaseInput node has an exception that is not handled successfully by the Catch terminal,
the transaction is rolled back and the event is marked as Failed, with a failure count incremented by 1.
When that Failed event is re-dispatched for processing, the retry mechanism is checked.
If set to 'Failure', the message is propagated down the Failure terminal, if wired.
If set to 'Short retry', it performs a number of retries equal to the Retry Threshold, propagating the message down the Out terminal with a delay between each retry equal to the 'Short retry interval'.
Once it has retried and rolled back a number of times equal to Retry Threshold, the message is then propagated down the Failure terminal.
If set to 'Short and long retry', it performs a number of retries equal to the Retry Threshold, propagating the message down the Out terminal with a delay between each retry equal to the 'Short retry interval'.
Once it has retried and rolled back a number of times equal to Retry Threshold, it then CONTINUES INDEFINITELY to retry the message but now with a delay between each retry equal to the 'Long retry interval'.
|
| Quote: |
2. If error occurs in DataBaseInput node, what are the actions taken?
If an error occurs during ReadEvents, i.e. reading the Events table to build a list of events to be processed, an error is logged to the system log. It will retry after the polling interval next expires.
No message is propagated down the Failure terminal because it hasn't managed to read an event to be processed (similar to not being able to read a message from an MQInput queue).
If an error occurs during BuildMessage processing, i.e. an event has been dispatched for processing, the exception is propagated down the Failure terminal if attached.
If exceptions are not handled on the failure terminal (i.e. it is not wired or an exception is thrown from the failure terminal), then the transaction is rolled back.
Otherwise, the transaction is committed.
In either case, whether the exception is handled or not, the message is not propagated to the out terminal and EndEvent is not invoked. |
| Quote: |
3. What happens if an error occurs in EndEvents.
An exception is thrown, the transaction is rolled back and the event marked as Failed. Retry processing is then as above. |
| Quote: |
4. Provide logic to call EndEvents from Failure path.
As described in my update last week, if the message has been processed down the Failure terminal due to DatabaseInput node error, or a previous message flow rollback,
the DatabaseInput EndEvent procedure does not get called to remove the event record from the event table.
If you want to do this to prevent re-processing of the event, you need to add a Compute or Database node down the Failure path and delete the event from the table explicitly.
I thought you should be able to easily call the EndEvent procedure itself, but this belongs to the DataBaseInput node ESQL Module, and therefore can't be called from another ESQL module.
The easiest way I've found is to code the DELETE call in the compute node, using the event id from LocalEnvironment.
e.g.
DELETE FROM Database.SFMFG.PWUE_ZQM_PRODUCT_REL_EVENTS
WHERE PWUE_ZQM_PRODUCT_REL_EVENTS.EVENT_ID = InputLocalEnvironment.Database.Input.Event.Usr.EVENT_ID;
Obviously need to add the DataSourceName to the Compute node properties.
If you did have complicated or lengthy 'EndEvent' processing that you didn't want to duplicate, it could be put in a common ESQL procedure, not defined within a node's module,
that can be called from both the DatabaseInput node module and from a Compute node. |
(of course the above SQL could also be an update of the EVENT_STATUS rather than a row delete)
| Quote: |
5. Why does the DataBaseInput node not follow similar failure handling logic to other input nodes, such as MQInput, that 'consume' the failed message if the failure path 'succeeds'?
By design, to give greater flexibility to the developer.
EndEvent is only called when an event has been successfully processed and the transaction committed.
EndEvent should be used to update the event store to ensure that the event that has just been processed cannot be processed again.
If the event processing has failed, it is up to the developer to decide how they wish to handle that failure.
The DatabaseInput node does not do a 'destructive' read/get of the event when building a message to be propagated, unlike the MQInput node which does an MQGET.
The event still exists in the event table after propagating from the DatabaseInput node.
It is left to the developer to decide what they want to do with that event after a failure. |
|
|
| 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
|
|
|
|
