Magic xpa Behavior (Magic xpa 4.x)
The question remains as to what will happen after the engine encounters a handler and executes it. After the engine has executed all the error handlers, or its own internal default handler, it will then perform what is known as an “engine directive” for that specific error. The directive works hand-in-hand with the Error Behavior Strategy defined in the program itself. This may be either Abort or Recover. This strategy defines how the task will behave when it encounters a database error.
Each error will have a different behavior under the Error Behavior Strategy. As an example, let us look at our scenario in which we received the Duplicate Index message. If the Error Behavior Strategy is defined as Recover, the engine directive for this error will be User Retry; meaning that the user can re-enter the data. On the other hand, if the Error Behavior Strategy was defined as Abort, the task will be aborted. As a different example, we can look at the Maximum Connections Exceeded error. If the Error Behavior Strategy is defined as Recover, then the Magic xpa engine directive will be Auto Retry without input from the user.
The developer can override these by re-defining the requested directive in the handler and giving a new directive. Let us take the Duplicate Index example again. The developer may define that when a duplicate index is encountered, the error is serious enough that the task must be aborted and all the work rolled back. The developer will then set the engine directive to Abort task in the handler.
|
Some of the engine directive options, such as "Ignore" are not valid for some of the errors. Some of the handlers, such as “Duplicate Index”, are only valid for deferred transactions. Please refer to the Reference Guide in the Magic xpa Help for more information.
|
Important:
|
The engine directive may be set for each error handler. However, the resulting directive that will be executed is defined at the level of the first handler that is executed.
|