The following example shows the effect of custom conflict handling using the custom conflict-handling function named custom_conflict_dept shown in Custom conflict handling function. This function sets the target node as the winner of update/update conflicts on the dept table.
The update is made on the primary definition node, edb:
The following update is made on a second primary node, MMRnode:
After a synchronization replication, the update/update conflict is detected and resolved as shown in the Conflict History tab.
In the source primary node, the loc column of department 50 loses the value set in its UPDATE statement. The column is reset to the value from the target primary node.
In the target primary node, the loc column of department 50 retains the value set from its UPDATE statement.
The target node wins the conflict as determined by setting the resolution_code parameter to 2 in the custom conflict-handling function.
Setting columns from the function logic
The following example shows the effect of custom conflict handling using the custom conflict-handling function custom_conflict_emp shown in Custom conflict-handling function. This function sets values coded in the function as the winner of update/update conflicts on the emp table.
The following is the row from the emp table prior to the update:
The following update is made in the primary definition node, edb:
The following update is made in a second primary node, MMRnode:
After the synchronization replication of the primary node, edb contains the following values for the conflicting row:
After the synchronization replication of the primary node, MMRnode, contains the following values for the conflicting row:
The value of the first conflicting column is determined by the custom conflict-handling function for both primary nodes.
Setting columns using the source and target shadow tables
The following example shows how to use the values from the source and target shadow tables to set the final values in the conflicting column.
Note
This custom conflict-handling function uses a column (rrep_old_quantity in this example) that's a column of the shadow table and not of the actual publication table. So you can't use this solution for a publication that uses the log-based method of synchronization replication.
This example use the following table, which contains product inventory.
When products are purchased at different locations, resulting in an inventory reduction on several primary nodes, the remaining inventory must be properly updated on all primary nodes to reflect the reduction in all locations. The custom conflict-handling function is coded to properly record the remaining inventory if changes to the same item are made in several locations.
The following example uses the primary definition node, edb and a second primary node, MMRnode. Initially, the inventory table has the same contents on both primary nodes.
After creating the primary nodes, the following shows the resulting shadow table structures in the primary definition node:
Similarly, in the second primary node the same shadow table is created.
For an update transaction, the shadow table contains the column values both:
Before the update was made on the publication table (columns with names rrep_old_column_name)
After the update was applied (columns named identically to the publication table column names)
The custom conflict-handling function uses both the current and old values of the quantity columns from the source and target shadow tables as shown by the following.
Assume two items with item_id of 1 are purchased on the primary definition node:
Also assume one item with item_id of 1 is purchased from the second primary node:
After the synchronization replication and invocation of the custom conflict handling function, the quantity column for item_id 1 is correctly set to 47 in both primary nodes: