SPL Conflict Resolution Rule
You can write an SPL routine as a primary conflict resolution rule or as secondary conflict resolution rule to the time stamp conflict resolution rule.
You have complete flexibility to determine which row prevails in the database when you create an SPL routine for conflict resolution. However, for most users, the time stamp conflict resolution rule provides sufficient conflict resolution. You can also use SPL routine to save information about the transactions that were discarded during conflict resolution.
SPL routines must follow the following guidelines:
- The owner of an SPL routine that is used for conflict resolution must be the same as the owner of the replicated table.
- Routines for conflict resolution must be in SPL. Enterprise Replication does not allow user-defined routines in C or in Java™.
- You cannot use an SPL routine or a time stamp with an SPL routine if the replicate is defined to replicate only changed columns or the replicated table contains any extensible data types. See Replicate only changed columns.
Enterprise Replication passes the following information to an SPL routine as arguments.
| Argument | Description |
|---|---|
| Server name [CHAR(18)] | From the local target row NULL if local target row does not exist |
| Time stamp (DATETIME YEAR TO SECOND) | From the local target row NULL if local target row does not exist |
| Local delete-table indicator [CHAR(1)] or Local key delete-row indicator [CHAR(1)] | Y indicates that the origin of the row is the delete
table. K indicates that the origin of the row is the replicate-key
delete row. If a conflict occurs while a replication key row is being deleted, because the local row with the old key no longer exists, the received key delete row is passed as the local row (using the seventh argument, local row data). The received key insert row is passed to the stored procedure as the replicated row using the eighth argument. |
| Server name [CHAR(18)] | Of the replicate source |
| Time stamp (DATETIME YEAR TO SECOND) | From the replicated row |
| Replicate action type [CHAR(1)] |
|
| Local row data that is returned in regular SQL format | Where the regular SQL format is taken from the SELECT clause of the participant list |
| Replicate row data after-image that is returned in regular SQL format | Where the regular SQL format is taken from the SELECT clause of the participant list |
The routine must set the following arguments before the routine can be applied to the replication message.
| Argument | Description |
|---|---|
| An indicator of the database operation to be performed [CHAR(1)] | Same as the replicate action codes with the following
additional codes
|
| A non-zero integer value to request logging of the conflict resolution and the integer value in the spooling files (INTEGER) | Logging value takes effect only if logging is configured for this replicate. |
| The columns of the row to be applied to the target table replicate action type in regular SQL format | This list of column values is not parsed if the
routine returns one of the following replicate action types: S, O,
or X. |
You can use the arguments to develop application-specific routines. For example, you can create a routine in which a database server always wins a conflict regardless of the time stamp.
- Any action that a routine takes as a result of replication does not replicate.
- You cannot use an SPL routine to start another transaction.
- Frequent use of routines might affect performance.
- An optimized SPL routine is called only when a collision is detected
and the row to be replicated fails to meet one of the following two
conditions:
- It is from the same database server that last updated the local row on the target table.
- It has a time stamp greater than or equal to that of the local row.
- A nonoptimized SPL routine runs every time Enterprise Replication detects a collision. By default, SPL routines are nonoptimized.