Conflict resolution


A number of different conflicts can occur when you update the data in a table. You can
specify how to handle the conflicts as they occur, depending on the conflict type:

  • Ignore the conflict.
  • Defer resolution until the job is complete.
  • Stop apply processing until the conflict is resolved.
  • Retry an SQL statement that generates a time-related conflict (such as time out conditions or RI-related conflicts).

Conflict resolution rules determine how the High-speed Apply Engine responds when a conflict occurs during apply processing. You create conflict resolution rules by defining sets of Code and Action parameters for each conflict to which you want to respond.

The following sections of its configuration file control how High-speed Apply Engine handles conflict resolution:

Consider these points about the configuration sections for conflict resolution:

  • The rules in the [AnyConflict] section apply to all types of statements (INSERT, UPDATE, DELETE, or EXCHANGE statements, as well as data definition language (DDL) statements). A rule that is defined in one of the other conflict sections, such as the [InsertConflcit] section, takes precedence over rules in the [AnyConflict] section.
  • If a statement doesn't start with INSERT, UPDATE, or DELETE, High-speed Apply Engine uses [DDLConflict] rules if they are defined. High-speed Apply Engine uses [DDLConflict] rules to process EXCHANGE statements.
  • The [Conflict] section describes general processing options for conflict management, particularly for retry processing.
  • The [ConflictFile] section defines the conflict file or files where High-speed Apply Engine writes output when the Action parameter of a conflict resolution rule is DeferStatement or DeferUR.
  • High-speed Apply Engine tracks the number of conflicts that trigger a conflict resolution rule during an apply request and displays the results in message BMCAPT0222.

Format of conflict resolution rules

A conflict resolution rule in any [xxxConflict] section consists of a Code parameter and one or more Action parameters, as shown in the following figure:

Code=<code>
Action=<action01>
Action=<action02>

The code value defines a Db2 SQL code or a conflict type (for more information, see Code parameter values). The action value defines the action that the High-speed Apply Engine takes when it encounters the conflict type that is defined by the code value (for more information, see Code parameter values).

If you specify more than one action for a code, the actions must be valid in the specified sequence. For example, if action01 in the preceding figure was specified as Abort, then action02 could never be performed. The following paragraph describes the codes and actions that you can define for these parameters:

Several actions cause High-speed Apply Engine to perform a commit action or a rollback action. For more information, see Actions for conflict resolution. The value of the DistributionType parameter or the CommitOnDemand parameter can limit commit or rollback actions to the COMMIT or ROLLBACK statements in your input. High-speed Apply Engine might perform additional commit or rollback actions in response to certain Action parameters of a conflict resolution rule or to resource shortages.

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

High-speed Apply Engine 13.1